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FOREWORD 


This  manual  contains  a  detailed  description  of  the  USAF 
PERT- Time  System.  It  provides  methodology  and  guidance, 

4  and  serves  as  a  reference  for  all  levels  of  management  in 

the  application  of  PERT. 

In  the  interests  of  achieving  uniformity  of  current  and 
future  extensions  of  PERT,  a  USAF  PERT  series  of  documents 
is  being  developed.  This  Manual  is  Volume  I  of  the  series. 

This  series  is  grounded  in  a  common  philosophy.  It  is 
interrelated  to  the  extent  that  each  volume  may  be  used 
independently  or  in  conjunction  with  any  other  volume  in 
the  series.  The  extent  of  usage  is  dependent  upon  the 
specific  requirements  of  any  given  program  or  the  manage¬ 
ment  desires  of  the  Program  Director  concerned. 

This  advanced  copy  is  effective  immediately  within  AFSC 
and  is  currently  being  coordinated  for  use  within  other 
Commands  by  Headquarters  USAF.  It  replaces  AFSC  PERT 
Policies  and  Procedures  Handbook,  ASD  Exhibit  ASOO  61-1, 
dated  5  January  1962. 

Comments  concerning  any  part  of  this  publication  are  solicited 
from  both  government  and  industry,  and  should  be  forwarded 
to  Headquarters  AFSC  (SCCS),  Andrews  AFB,  Washington  25, 
D.  C. 

£2 - r 

DUWARD  L.  CROW 
Brigadier  General,  USAF 
DCS/Comptroller 
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USAF  has  produced  a  series  of  PERT  documents  to  provide 
understanding  of  the  USAF  PERT  TIME  and  PERT  COST  Systems 
presently  in  use.  This  manual,  Volume  I,  is  the  first  in 
the  USAF  PERT  series. 
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PREFACE 


The  Program  Evaluation  and  Review  Technique  (PERT) , 
in  a  broad  sense ,  represents  the  concept  of  an  integrated 
management  system  which  can  be  used  by  program  managers  in 
controlling  the  variables  of  time,  cost,  and  technical 
performance.  A  major  step  in  the  development  of  this 
concept  was  completed  in  1958  triien  PERT  was  implemented 
for  planning  and  control  of  the  time  variable  in  research 
and  development  work. 

This  manual  describes  detailed  methods  of  PERT  TIME 
applications  which  are  used  by  the  Air  Force  and  suggested 
for  use  by  its  contractors.  This  manual  can  stand  by 
itself  in  its  coverage  of  PERT  TIME.  It  contains  general 
concepts,  principles,  and  methods,  as  well  as  specific 
material  related  to  a  given  computer  program  operation. 
However,  the  manual  is  related  to  other  documents  which 
should  be  examined  by  the  reader  for  more  comprehensive 
understanding  of  the  broad  scope  of  PERT.  Some  of  the 
other  documents  are: 

POD  Documents 


PERT  Guide  for  Management  Use 

POD  and  NASA  Guide;  PERT  COST  Systems  Design 

Supplement  No.  1  to  POD  and  NASA  Guide; 

PERT  COST  Output  Reports 
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USAF  Documents 


USAF  PERT  TIME  System  Computer  Program  Handbook1 

USAF  PERT  COST  System  Description  Manual 

USAF  PERT  COST  System  Computer  Program  Handbook-Part  I  2 

USAF  PERT  COST  System  Computer  Program  Handbook-Part  II3 

USAF  PERT  Implementation  Manual 

A  goal  of  this  manual  is  the  attainment  of  uniformity 
in  Air  Force  applications  of  PERT  TIME.  Since  PERT  COST 
requires  inputs  from  PERT  TIME,  this  data  should  be  as 
uniform  as  possible  during  the  development  of  PERT  COST 
techniques. 

Although  there  are  several  PERT  TIME  computer  programs 
which  may  be  used  to  process  the  data  and  produce  the  desir¬ 
ed  outputs,  only  one  such  program  is  discussed  in  this 
manual.  Consequently,  the  illustrations  and  detailed 
description  of  output  reports  in  Chapter  XI  refer  to  the 
format  in  which  data  is  printed  out  when  using  the  Air 
Force  program.  Essentially  the  same  output  information 
can  be  produced  by  any  PERT  TIME  computer  program.  The 
program  was  developed  for  the  specific  purpose  of  incor¬ 
porating  as  many  of  the  features  desired  by  Air  Force  and 
industry  users  as  possible  without  overloading  the  program 
to  the  extent  that  processing  time  would  become  prohibitive. 
The  program  will  therefore  produce  outputs  that  may  contain 
information  considered  extraneous  to  certain  users.  With 
a  thorough  understanding  of  basic  PERT  concepts  and  opera¬ 
tion,  the  user  can  select  the  information  pertinent  to  his 
particular  requirements  from  the  variety  of  outputs  avail¬ 
able. 


1  Formally  AFSC  PERT  III  Computer  Program  Handbook. 

3  Formerly  AFSC  PERT  COST  System  Cost  Module  -  Vol.  I. 

3  Formerly  AFSC  VBKF  GOST  System  Cost  Nodule  -  Vol.  IX. 
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The  material  for  this  manual  was  arranged  in  a  sequence 
which  permits  the  reader  to  advance  from  the  basic  concepts 
through  the  mechanics  to  the  PERT  TIME  System  operation. 
Chapter  II  introduces  the  basic  PERT  concepts.  Chapters  III, 
IV,  and  V  explain  the  mechanics  of  PERT  TIME.  Chapters  VI 
through  XIII  describe  the  PERT  TIME  System  operation. 
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CHAPTER  I 


INTRODUCTION 


CHAPTER  I 


INTRODUCTION 


Management  like  invention  is  no  longer  a  matter  of 
individual  effort;  Space-Age  programs  are  too  complex. 


Management  of  major  space,  weapons,  construction,  military 


or  other  programs  is  accomplished  through  large  organiza¬ 
tions  of  professional  experts  in  administration,  finance, 
science,  engineering,  and  production,  to  list  but  a  few. 


In  the  task  of  acquiring  modern  aerospace 
systems  today,  the  pacing  factor  is  manage- 
ment-not  science  or  technology.  Management 
is  the  element  that  directs,  guides,  coordinates, 
and  controls  the  many  aspects  of  system  develop¬ 
ment.  The  need  to  utilize  all  our  research  and 
development  resources  effectively,  efficiently, 
and  on  a  timely  basis  and  the  need  to  translate 
new  discoveries  into  new  weapons  with  the  shortest 
possible  lead  time-these  are  our  two  basic 
management  problems  in  maintaining  technological 
supremacy  today. 


Not  only  must  new  systems  embody  the  latest  technical 
developments;  they  must  also  become  operational  in  time  to 
meet  future  needs.  Each  program  must  be  carefully  planned, 
scheduled,  evaluated,  and  managed  toward  attainment  of  specific 
objectives.  The  complexity  of  directing  and  controlling  these 
programs  has  challenged  conventional  management  techniques. 

A.  Program  Evaluation  and  Review  Technique  (PERT) 

PERT  represents  a  significant  step  toward  an  integrated 
management  system  encompassing  the  variables  of  time,  resources, 
and  technical  performance.  The  improved  planning  produced 
by  PERT  offers  a  sound  basis  for  scheduling  as  a  means  by 


1 - 

General  Bernard  A.  Schriever,  "The  Role  of  Management  in  Technological 
Conflict",  Air  University  Quarterly  Review.  Winter  and  Spring  1962 
and  1963,  pp.  20,  Vol  XIV,  No«.  1  and  2. 
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which  status  may  be  measured  and  current  and  potential 
problems  detected  in  time  to  take  corrective  action.  It 
provides  the  integrative  discipline  for  government  and 
corporate  managers  at  all  levels  necessary  for  the  defini¬ 
tion,  communication,  and  successful  attainment  of  the  prime 
and  supporting  objectives  of  the  plan. 

PERT  is  a  set  of  principles,  methods,  and  techniques 
for  planning  of  objective-oriented  work  thereby  establishing 
a  sound  basis  for  effective  scheduling  and  controlling  and 
replanning  in  the  management  of  programs. 

It  employs : 

.  a  product-oriented  work  breakdown  structure, 
beginning  with  these  objectives  subdivided  into 
successively  smaller  end-items; 

.  a  flow  plan  (called  a  network)  consisting  of  all 
the  activities  and  events  that  must  be  accomplished 
or  completed  to  reach  the  program  objectives, 
showing  their  planned  sequence  of  accomplish¬ 
ment,  interdependencies,  and  interrelationships; 

.  elapsed  time  estimates  and  identification  of 
critical  paths  in  the  networks r 

.  a  schedule  which  attempts  to  balance  the  objec¬ 
tives,  the  network  flow  plan,  and  resources 
availability; 

.  analysis  of  the  interrelated  networks,  schedules 
and  slack  values  as  a  basis  for  continuous 
evaluation  of  program  status,  forecast  of 
overruns,  and  the  identification  of  problem 
areas  in  time  for  management  to  take  correc¬ 
tive  action. 

This  basic  PERT  technique  is  flexible  enough  to  en¬ 
compass  effectively  a  variety  of  objectives  and  applications 
including  allocation  of  resources  to  serve  several  concurrent 
projects. 
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B.  PERT  and  the  Management  Process 


PERT  provides  clear  concise  reports  for  top  management 
in  order  to  evaluate  status  of  completed  work  and  forecast 
or  identify  potential  problems. 

PERT  aids  managers  from  the  inception  to  the  completion 
of  a  program.  Although  PERT  can  be  introduced  in  any  phase 
of  a  program,  its  full  potential  is  realized  only  when  it 
is  utilized  in  all  phases  by  both  government  and  industry. 

In  this  manner,  PERT  correlates  the  many  aspects  of  a  com¬ 
plete  program  and  provides  continuity  through  each  of  the 
three  phases: 

.  Pre-contract  Phase; 

.  Contract  Negotiation  Phase;  and 

.  Contract  Management  Phase . 

Government  use  of  PERT  assures  industrial  management  that: 

.  the  objectives  of  the  program  and  interrelated 
aspects  have  been  defined,  evaluated,  and  com¬ 
municated  before  a  request  for  proposal  is  issued; 

.  contract  awards  are  made  on  the  basis  of  defini¬ 
tive  analyses  and  improved  evaluations. 

Similarly,  government  management  is  assured  that: 

.  industry  has  improved  opportunity  to  plan, 
bid,  and  manage  a  program. 

.  more  precise  planning  and  control  over 
resources  exists; 

.  negotiations  can  be  conducted  in  a  more 
informed  manner. 

Both  government  and  industrial  management  benefit  from 
the  common  use  of  PERT.  It  makes  a  team  of  the  highest  and 
lowest  level  of  government  agencies,  field  establishments, 
and  industry  by  serving  as  a  means  of  communication  in  all 
phases  of  the  program.  It  is  especially  useful  in  construc¬ 
tion  projects,  system  development,  production  engineering. 
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and  few -of -a -kind  production  programs.  When  a  high  volume 
production  program  passes  the  production  engineering  or 
prototype  production  and  test  phase,  other  techniques  may 
prove  more  appropriate.  However,  these  must  be  compatible 
with  an  overall  network  management  technique  suitable  for 
planning,  scheduling,  and  controlling  the  entire  system 
from  conception  to  operation. 

Contractual  arrangements,  whether  they  are  fixed  price, 
cost-plus-fixed-fee,  or  incentive  variations  of  either,  do 
not  affect  the  applicability  of  PERT.  The  type  of  contract, 
however,  may  influence  the  emphasis  placed  on  the  use  of 
PERT  by  either  government  or  industry.  For  example,  a 
contractor  may  elect  to  use  PERT  on  a  firm  fixed-price  con¬ 
tract,  even  though  its  use  may  not  be  required  by  the  con¬ 
tracting  authority.  Conversely,  on  a  cost-plus-fixed-fee 
contract,  the  government  may  be  equally  as  concerned  as 
the  contractor  with  the  use  of  PERT  for  program  control. 

PERT: 

.  provides  disciplines  which  insure  complete 
program  coverage,  avoids  omission  of  impor¬ 
tant  tasks  at  the  outset  of  a  program,  and 
provides  visibility  from  the  total  program 
objective  down  to  the  lowest  supporting 
task; 

.  fixes  responsibility  and  assures  continuity 
of  effort  despite  turnover  in  either  executive 
or  operating  personnel; 

.  assists  in  identifying  real  time  requirements 
and  provides  limits  for  detailed  scheduling; 

.  spots  potential  problem  areas  in  time  for 
preventive  action  or  for  improvement; 

.  uses  the  management-by -exception  principle 
in  reporting  to  higher  levels  of  management; 

.  measures  accomplishment  against  current 
scheduled  plans  and  objectives; 
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provides  an  opportunity  for  consideration 
of  trade-offs  in  funds,  manpower,  performance, 
and  time  between  critical  and  noncritical  areas 
of  effort  as  a  means  of  improving  schedule  plans 
for  one  or  more  programs; 

permits  rescheduling  and  provides  periodic 
evaluation  of  plans; 

makes  it  possible  through  its  simulation 
techniques  to  evaluate  and  forecast  out¬ 
comes  of  alternate  plans  before  imple¬ 
mentation; 

provides  a  historical  data  bank  for  the 
program  which  can  be  drawn  upon  for  new 
programs. 
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PERT  CONCEPTS 


A  brief  discussion  of  the  basic  PERT  concepts  is 
presented  here  to  prepare  the  reader  for  the  detailed 
treatment  to  follow. 

A.  The  PERT  Network 


1.  Description 

The  PERT  network  is  a  graphic  description  of  the  plan 
showing  the  sequential  steps  needed  to  reach  a  stated  objec¬ 
tive  (for  example,  the  R&D,  testing,  tooling,  establishment 
of  a  logistics  system,  etc. ,  that  are  needed  to  make  a  sys¬ 
tem  operational).  The  network  must  be  comprehensive  and 
include  all  significant  interdependencies  and  interactions 
required  to  perform  the  program.  However,  judgment  must  be 
exercised  to  limit  the  level  of  detail  to  that  which  will 
best  serve  the  objectives  of  management. 

Networks  define  activities  and  interrelationships  be¬ 
tween  activities.  They  are  an  improvement  over  the  Gantt 
chart,  which  shows  activities  but  either  does  not  indicate 
their  relationships  or,  at  best,  indicates  only  a  vague 
relationship  in  time.  They  are  also  an  improvement  over 
the  milestone  charts,  which  describe  points  in  time  when 
various  items  are  complete  or  available  but  not  the  inter¬ 
relationships  among  these  items.  These  charts  usually  fail 
to  identify  the  progress  which  must  be  made  in  one  task 
before  subsequent  tasks  can  begin.  PERT  networks,  unlike 
milestone  charts,  recognize  the  progress  which  must  be  made 
in  one  task  before  subsequent  tasks  can  begin.  The  iden¬ 
tification  of  activities  and  their  points  of  interaction 
is  an  essential  of  networking.  Figure  II-l  shows  a  com¬ 
parison  of  the  Gantt  chart,  the  milestone  chart,  and  the 
PERT  network. 

2.  Events 

By  PERT  definition,  an  event  is  a  specific,  definable 
accomplishment  in  a  program  plan,  recognizable  at  a  particu¬ 
lar  instant  in  time.  Events  do  not  consume  time  or  resources. 
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An  example  of  two  events  is  shown  below.  Circles, 
squares,  rectangles,  or  other  geometric  figures  are  used 
to  represent  events  in  the  network. 


Events  are  the  basis  for  status  monitoring  and  often 
for  partially  describing  the  activities  which  lie  between 
them.  Care  must  be  exercised  that  events  are  clearly  defined 
and  therefore  meaningful. 

The  use  of  network  events  is  demonstrated  in  Figure  II-2. 
This  simplified  network  shows  the  key  events  that  are  re¬ 
quired  in  an  aircraft  development  task. 

3.  Activities 

Activities  are  the  work  efforts  of  a  program.  They 
represent  the  action  of  the  network,  such  as  preparing, 
designing,  building,  testing,  negotiating,  etc.  It  is 
these  time-consuming  elements,  whether  they  be  human  effort, 
use  of  facilities,  or  use  of  materials,  that  the  managers 
must  attempt  to  control. 

An  activity  is  represented  on  a  PERT  network  by  an 
arrow  which  links  two  successive  events,  as  shown  in  Figure  II-2. 
While  an  activity  is  normally  time-consuming,  it  may  simply 
represent  a  relationship  of  interdependency  between  two 
events  on  the  network. 

4.  Constraints 

The  term  "constraint"  is  used  to  indicate  the  relation¬ 
ship  of  an  event  to  a  succeeding  activity  wherein  an  activity 
may  not  start  until  the  event  preceding  it  has  occurred  and 
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FIGURE  H-2  —  PERT  NETWORK  CONSTRUCTED  OF  EVENTS  AND  ACTIVITIES 


the  relationship  of  an  activity  to  a  succeeding  event  where¬ 
in  an  event  cannot  occur  until  all  activities  preceding  it 
have  been  completed. 

These  event  and  activity  relationships  are  illustrated 
below. 


Event  A  constrains 
Activities  A-B  and 
A-C. 


Activities  D-F  and 
E-F  constrain  Event 
F. 


B.  Time  Estimating 

The  time  required  to  perform  each  activity  in  the 
network  must  be  estimated.  These  estimates  are  based 
on: 

.  planned  manpower  or  other  resources; 

.  average  resource  application  rates  or  work 
schedules  (the  40-hour  week,  the  number  of 
shifts,  etc.). 

Because  of  the  uncertainty  involved  in  the  duration  of 
some  activities,  a  range  of  estimates  is  usually  made.  In 
this  case,  an  optimistic,  a  most  likely,  and  a  pessimistic 
time  estimate  is  made  for  each  activity.  These  activity 
estimates  are  defined  as  follows: 
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.  Optimistic  Time  Estimate  (a)  The  time  in 
which  the  activity  can  be  completed  if 
everything  goes  exceptionally  well.  It  is 
estimated  that  an  activity  would  have  no  more 
than  one  chance  in  a  hundred  of  being  com¬ 
pleted  within  this  time. 

.  Most  Likely  Time  Estimate  (m)  The  most 
realistic  estimate  of  the  time  an  activity 
might  consume.  This  time  would  be  expected 
to  occur  most  often  if  the  activity  could  be 
repeated  numerous  times  under  similar  circum¬ 
stances. 

.  Pessimistic  Time  Estimate  (b)  An  estimate 
of  the  longest  time  an  activity  would  require 
under  the  most  adverse  conditions,  barring 
acts  of  God. 

A  statistically  derived  "expected  elapsed  time"  (te) 
for  the  activity  is  then  determined  from  the  three  time 
estimates.  The  three  time  estimates  and  the  resultant 
expected  elapsed  time  are  illustrated  on  the  activity  lines 
of  Figure  II-3. 

In  some  areas,  e.g.  commercial  construction,  most  of 
the  activities  are  well-defined,  and  it  may  not  be  neces¬ 
sary  to  use  more  than  one  time  estimate.  When  a  single 
time  estimate  is  given  for  an  activity,  it  is  used  in  all 
subsequent  calculations  in  the  same  manner  as  the  expected 
time  (te)  calculated  from  the  three  time  estimates. 

C.  Slack  and  the  Critical  Path 

1.  Expected  Date  (TP) 

After  calculating  the  expected  elapsed  times  (t  ) ,  the 
next  step  is  to  sum  these  times  throughout  the  various  net¬ 
work  paths  to  determine  the  total  expected  elapsed  time  for 
the  program.  This  accumulated  activity  time  establishes 
the  expected  date  (Tg)  for  the  program.  Tg  is  also  calcu¬ 
lated  for  each  event  in  the  network  and  shown  in  Figure  II-4 
expressed  in  terms  of  time  rather  than  calendar  dates. 
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FIGURE  II-3— PERT  NETWORK  WITH  TIME  ESTIMATES  AND  CALCULATED 
EXPECTED  ELAPSED  TIMES  (te) 
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FIGURE  1-4  —  PERT  NETWORK  WITH  CALCULATED  TIMES 


Since  there  are  several  activities  leading  into  some 
events,  there  will  be  a  choice  of  T  '  s  for  those  events  (one 
for  each  path  leading  into  the  event) .  Since  no  event  can 
occur  until  all  activities  leading  into  it  have  been  completed, 
the  latest  of  these  possible  TE's  is  assigned  to  the  event. 

2.  Latest  Allowable  Date  (T^) 

is  defined  as  the  latest  calendar  date  on  which  an 
event  can  occur  without  creating  an  expected  delay  in  the 
completion  of  the  program.  The  T^  value  for  a  given  event 
is  calculated  by  subtracting  the  sum  of  the  expected  elapsed 
times  (te)  for  the  activities  on  the  longest  path  between 
the  given  event  and  the  end  event  of  the  program  from  the 
latest  date  for  completing  the  program.  The  TL's  expressed 
in  terms  of  time  rather  than  calendar  dates  are  shown  in 
Figure  II-4. 

3.  Determination  of  Slack  and  the  Critical  Path 

Slack  is  the  time  difference  between  the  latest  allow¬ 
able  date  and  the  expected  date:  Slack  =  TL  -  TE.  It  can 
have  a  positive,  negative,  or  zero  value.  When  the  latest 
allowable  date  (TL)  is  later  than  the  expected  date  (TE) 
positive  slack  exists.  Positive  slack  is  "time  to  spare". 

The  path  in  the  network  that  has  minimum  slack  is  the 
longest  time  path  and  therefore  is  called  the  critical  path. 

It  is  characterized  by  the  fact  that  a  slip  in  an  activity 
time  along  the  critical  path  will  cause  an  equal  slip  in 
the  expected  completion  date  of  the  end  event.  In  Figure  II-4 
it  is  the  path  shown  as  a  heavy  line.  In  the  example,  all 
events  along  this  path  have  zero  slack.  Zero  slack  occurs 
along  a  path  when  T^  =  T£  for  all  events  on  that  path  through 
the  network. 

If  the  latest  allowable  date  (TL)  for  the  end  event 
occurs  before  the  expected  date  (Tg)  for  the  end  event,  the 
end  event  must  be  expected  to  occur  behind  schedule  unless 
some  action  is  taken.  (In  this  case,  the  critical  path, 
and  perhaps  other  paths,  will  have  negative  slack.)  Thus 
the  program  manager ' s  attention  is  focused  on  those  areas 
most  warranting  management  action. 
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NETWORK  DEVELOPMENT 


This  chapter  describes  the  mechanics  of  constructing 
networks. 

A.  Guidelines  for  Network  Construction 

Construction  of  the  networks  should  be  initiated  by 
a  team  of  personnel  familiar  with  the  objectives  and  re¬ 
quirements  of  the  program  and  experienced  in  the  functional 
areas  involved.  A  member  of  the  local  PERT  staff  office 
should  participate  in  this  initial  effort.  Later,  networking 
may  be  continued  by  program  personnel  without  the  assistance 
of  outside  specialists. 

1.  Program  Control  Events  and  Activities 

Prior  to  actual  network  construction,  the  program 
milestones  which  are  to  be  included  must  be  available  in 
their  logical  sequence  as  an  initial  guide  line,  and  all 
activity  and  event  definitions  and  responsibilities  must 
be  agreed  on.  Agreement  on  definitions  and  responsibili¬ 
ties  is  especially  important  when  an  event  is  common  to 
one  or  more  functions  and  is  identified  as  an  interface 
event . 


2.  Construction  Methodology 

Experience  has  shown  that  there  are  advantages  in 
constructing  a  PERT  network  by  starting  with  the  end  objec¬ 
tive  of  the  program  and  proceeding  backward  to  the  beginning 
or  start  event.  Since  the  end  objective  is  constantly  and 
clearly  in  view,  the  plan  may  be  developed  in  direct  relation 
to  it. 

If  network  construction  were  to  begin  instead  at  the 
start  event,  the  question  "What  comes  next?"  is  asked  as 
each  event  is  defined.  This  procedure  continues  through  a 
functional  area  to  reach  its  objective  and  then  begins  again 
in  another  functional  area.  The  network  is  not  constructed 
with  direct  relation  to  the  end  event. 
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However,  if  network  construction  starts  at  the  end 
event,  the  question  is  asked  "What  activities  must  be  com¬ 
pleted  before  this  event  is  completed?"  This  avoids  the 
question  of  what  can  occur  now  and  substitutes  the  more 
objective  question  of  what  must  have  occurred  in  relation 
to  the  end  event.  The  "must-have-occured"  question  will 
result  in  an  initial  network  with  fewer  personal  biases 
and  therefore  a  more  objective  and  inclusive  picture  which 
may  be  modified  as  needed. 

3.  Rules  of  Logic 

The  fundamental  rule  of  logic  for  network  construction 
lies  in  the  observance  of  the  constraint  relationship.  The 
term  constraint  is  used  to  indicate  the  relationship  of  an 
event  to  a  succeeding  activity  wherein  an  activity  may  not 
start  until  the  event  preceding  it  has  occurred  and  the 
relationship  of  an  activity  to  a  succeeding  event  wherein 
an  event  cannot  occur  until  all  activities  preceding  it 
have  been  completed. 

Other  rules  that  must  be  observed  in  network  construc¬ 
tion  are: 

.  An  event  must  oe  unique,  i.e.,  it  appears  only 
once  in  the  network. 

.  An  event  can  appear  only  once  in  any  continuous 
path,  i.e.,  the  network  must  not  contain  a  loop. 

.  Activities  must  be  able  to  take  place  indepen¬ 
dently  of  each  other  and  must  not  require  inputs 
other  than  those  shown  by  the  network  as  feeding 
into  the  initiating  event. 

.  The  activities  in  a  series  with  each  other  must 
also  be  independent,  i.e.,  the  time  which  one 
takes  must  not  affect  the  time  which  any  of 
the  others  take. 

.  Only  one  activity  or  constraint  time  may  connect 
any  pair  of  events. 


Ill -2 


4.  Zero-time  Activity 


Another  aspect  of  constraint  is  the  zero-time  activity. 
A  zero- time  activity  is  an  activity  which  constrains  the 
completion  of  the  event  to  which  it  leads  by  requiring 
that  the  event  from  which  it  proceeds  be  completed  first. 

It  has  no  elapsed  time  associated  with  it,  i.<a.,  the  time 
estimate  is  zero.  It  is  often  used  to  tie  the  completion 
>f  several  activities  to  the  beginning  of  a  single  activity, 
>r  vice  versa. 

The  zero-time  activity  may  also  be  used  when  it  is 
iesirable  to  indicate  by  separate  events  the  ending  of 
ane  activity  and  the  beginning  of  the  following  one.  This 
nay  be  desirable  in  cases  where  the  completion  of  one 
activity  is  of  major  significance  and  where  it  is  necessary 
to  assure  that  the  following  activity  begins  immediately 
as  planned.  Illustrated  below  is  a  zero-time  activity  be¬ 
tween  two  events  to  show  the  completion  of  one  activity  and 
the  beginning  of  another  activity. 


B.  An  Example  of  Network  Development 

An  example  of  network  development  is  shown  in  the 
following  pages.  In  the  network  to  be  developed,  the 
delivery  of  the  first  operational  unit  of  a  program  was 
selected  as  the  end  objective  or  final  event.  The  event 
is  placed  on  the  network  worksheet  at  the  far  right  as 
depicted  below. 
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DELIVERED 


This  example  assumes  that  the  operational  unit  con¬ 
sists  of  five  major  components:  the  missile,  a  missile 
site,  equipment  to  fire  the  missile,  equipment  to  maintain 
both  the  missile  and  the  ground-based  equipment,  and  per¬ 
sonnel  to  operate  the  site,  maintain  the  equipment,  and 
if  necessary,  launch  the  missile.  Figure  III-l  shows  that 
delivery  of  the  first  unit  is  dependent  on  all  five  of 
these  components. 

In  analyzing  this  limited  network,  a  problem  of  logic 
is  apparent:  Do  all  five  components  have  a  direct  relation¬ 
ship  to  the  first  unit  delivery  or  are  they  interrelated 
as  shown  in  Figure  III-2.  This  latter  relationship  required 
installation  of  the  missile  and  ground  equipment  before  the 
launch  site  may  be  considered  complete.  It  can  be  assumed 
that  the  relationship  shown  in  Figure  III-2  is  correct. 

Note  that  the  definitions  of  the  Missile  and  Ground  Equip¬ 
ment  Events  have  been  changed.  These  are  now  starts  of 
installation  activities  as  well  as  completion  of  other 
activities  to  be  defined. 

The  activity  lines  leading  from  the  Missile  and  Ground 
Equipment  Events  represent  the  installation  activities. 

The  activity  lines  between  the  Launch  Site  Completed, 
Equipment  Available,  and  Personnel  Available  Events,  and 
the  Delivery  Event  may  or  may  not  require  activity  time. 

If  not,  a  zero  time  would  be  assigned  to  these  activities 
to  indicate  simply  that  these  events  must  occur  before 
delivery  is  considered  complete. 


Ill -4 


FIWHtBI-l  —  NETWORK  CONSTRUCTION 


FIGURE  IE-2  -  NETWORK  CONSTRUCTION  (FURTHER  DETAIL) 
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Figure  III-3  illustrates  the  process  of  continuing 
the  network  construction  toward  the  program  start.  (Note 
that  in  Figure  III- 3,  the  Construction  Complete  Event  is 
connected  to  both  the  Missile  and  Ground  Equipment  Instal¬ 
lation  starts,  as  well  as  the  Launch  Site  Completed  Events, 
indicating  that  construction  must  be  complete  before  any 
of  these  events  can  occur.) 

At  this  point,  it  may  be  easier  to  establish  the 
series  of  activities  that  lead  up  to  each  of  the  events 
now  existing  in  the  network.  The  planner  may  follow  a 
sequence  of  thoughts  such  as  the  following  which  refer  to 
the  Missile-On-Dock  Event: 

.  "What  is  necessary  to  start  loading  the 
missile?"  -  a  transportation  vehicle,  the 
missile  itself,  and  equipment  to  place  the 
missile  on  the  vehicle.  All  of  these  must 
be  complete  and  ready  and  consequently  shown 
as  completed  events. 

.  "What  is  necessary  to  have  the  missile  com¬ 
plete  and  ready  to  load?"  -  it  needs  to  be 
tested.  This  can  be  a  start  event. 

.  "What  is  necessary  to  start  the  testing  oper¬ 
ation?"  -  testing  equipment,  a  place  to  conduct 
the  test,  and  an  assembled  and  physically  com¬ 
plete  missile. 

This  examination  results  in  a  progressively  more 
complex  network  eventually  leading  back  to  the  source  of 
the  network. 

Figure  III-4  is  an  example  of  a  simple  or  broadly 
defined  network  which  may  be  drawn  in  the  early  phases  of 
a  program.  Detail  is  added  progressively  by  inserting 
related  events  between  those  already  established  in  the 
broad  network.  Figure  III-5  illustrates  this  process. 

As  activity  and  event  definition  progresses,  the 
interdependencies  between  elements  of  the  program  must  be 
identified.  There  are  many  interdependencies  between 
elements  such  as  the  missile,  missile  handling  equipment, 
ground  equipment,  installation  and  checkout  equipment,  etc. 

For  example,  the  design  of  the  handling  equipment  must  account 
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FIGURE  m-5—  NETWORK  CONSTRUCTION  (FURTHER  DETAIL) 
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Ill-  9 


FIGURE  IE-4  —  COMPLETED  DETAILED  NETWORK 
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FIGURE  III-5- INSERT  ION  OF  ADDITIONAL  DETAIL 


for,  as  one  of  its  inputs,  the  dimensions,  weights,  etc. , 
of  the  missile  itself. 

The  network  in  Figure  III-6  illustrates  these  inter¬ 
dependencies  and  indicates  that  certain  preliminary  missile 
data  must  be  made  available  to  the  group  designing  handling 
equipment  before  they  can  begin  detail  design.  Prior  to 
that  point,  there  could  be  some  design  work  of  a  broad 
nature,  and  prior  to  starting  a  final  handling  equipment 
design  review,  the  missile  design  should  be  reviewed  to 
resolve  any  inconsistencies  caused  by  changes  to  the  pre¬ 
liminary  missile  design. 

A  similar  relationship  exists  when  a  series  of  activi¬ 
ties  which  are  normally  planned  end  to  end  are  replanned 
in  parallel.  Figure  III-7  shows  an  example  of  a  network 
which  has  been  replanned  to  recognize  the  interrelation¬ 
ships. 

In  Figure  III-8,  the  sample  network  has  been  partially 
expanded  to  recognize  interdependencies.  Note  that  events 
which  are  internal  to  a  function  have  been  added  for  the 
sole  purpose  of  expressing  interrelationships  with  other 
functions. 

Initial  layout  of  the  sample  network  is  now  completed. 
C.  Event  Identification 


Code  numbers  are  assigned  to  all  events  in  order  to 
identify  them  adequately  for  computer  processing.  USAF 
PERT  uses  eight  (8)  digit  event  numbers.  This  is  sub¬ 
divided  so  that  significant  coding  can  be  applied  to 
identify  specific  networks,  program  functions,  items,  and 
hardware  and  components. 

Events  are  normally  numbered  by  placing  low  order  num¬ 
bers  on  the  left  or  beginning  of  the  network.  However,  in 
the  USAF  PERT  random  assignment  of  event  numbers  will  create 
no  problem  in  computer  processing,  e.g. ,  30-100-002  need 
not  precede  30-100-003.. 

The  event  number,  title,  and  other  data  may  be 
identified  within  the  event  rectangle  as  illustrated  in 
Figure  III-9. 
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FIGURE  m-6  -  INTERDEPENDENCIES  BETWEEN  PARALLEL  EFFORTS 


III-13 


FIGURE  HT-7 —  RECOGNITION  OF  PARALLEL  EFFORTS 
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FIGURE  ID-8—  DETAILED  NETWORK  EXPANDED  TO  SHOW  INTERDEPENDENCES 
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FIGURE  m-9  —  SAMPLE  EVENT  BLOCK 
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CHAPTER  IV 


TIME  CALCULATIONS 


This  chapter  describes  the  calculations  necessary  for 
understanding  and  operating  the  PERT  TIME  System.  A  simple 
9-event,  14-activity  network  shown  in  Figure  IV-1,  is  used 
as  a  sample  network.  To  simplify  the  explanations,  the 
events  in  the  sample  network  were  assigned  one-digit  event 
numbers,  and  the  standard  format  was  not  used. 

A.  Establishment  of  the  Time  Estimates 


As  previously  stated,  each  activity  in  the  network  must 
be  assigned  time  estimates.  Since  all  calculations  are 
based  on  these  estimates,  it  is  imperative  that  they  be  as 
accurate  as  possible. 

The  estimates  should  be  made  without  regard  to  calen¬ 
dar  or  schedule  dates  and  under  the  assumption  that  all 
resources  necessary  to  accomplish  an  activity  are  available 
during  a  normal  work  period. 

The  first  time  estimate  to  be  established,  is  the 
"most  likely"  time.  It  is  the  most  realistic  estimate  of 
the  time  an  activity  might  consume.  This  time  would  be 
expected  to  occur  most  often  if  the  activity  could  be 
repeated  numerous  times  under  similar  circumstances. 

The  second  estimate,  the  "optimistic  time",  is  the 
time  in  which  the  activity  can  be  completed  if  everything 
goes  exceptionally  well.  It  is  estimated  that  an  activity 
would  have  no  more  than  one  chance  in  a  hundred  of  being, 
completed  within  this  time. 

The  third  estimate,  the  "pessimistic  time",  is  an 
estimate  of  the  longest  time  an  activity  would  require  under 
the  most  adverse  conditions,  barring  acts  of  God. 

When  the  estimates  are  established,  they  are  entered 
on  the  applicable  network  activity  line  in  the  order  of 
optimistic,  most  likely,  and  pessimistic  as  shown  in  Figure  IV-1. 
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FIGURE  ff-l —  COMPUTATION  OF 


For  computational  purposes,  these  values  have  also  been  listed 
in  the  table  appearing  in  Figure  1V-1.  The  zero  time  value 
between  Events  4  and  5  in  this  network  indicates  a  constraint 
with  no  work  content. 

It  is  essential  that  the  time  estimate  for  each  activity 
be  made  by  the  individual  responsible  for  its  execution  (or 
if  the  responsibility  has  not  been  established,  as  in  the  case 
of  developing  a  proposal,  by  the  individual  with  the  most 
experience  in  siitiilar  types  of  activity) .  As  the  program 
progresses  it  is  the  responsible  manager  who  can  best  be 
expected  to  learn  progressively  more  about  his  activity  and 
to  sense  changes  in  the  situation.  The  ability  of  the  PERT 
System  to  provide  predictions  of  problems  far  enough  in 
advance  to  permit  management  to  resolve  them  is  based  on  the 
manager's  ability  to  translate  these  changes  into  new  time 
estimates. 

There  are  some  activities,  such  as  the  Curing  of  Concrete 
to  Specifications,  which  require  a  predictable  or  known  period 
of  time,  in  which  case  the  three  time  estimates  may  be  equal. 

B.  Expected  Elapsed  Time  (te) 

The  three  time  estimates  are  converted  to  a  single 
calculated  expected  elapsed  time  by  the  simple  approximation 
formula  te  =(a  +  4%  +  j?  J  .  The  expected  elapsed  time  is  a 
statistically  weighted  average  of  the  three  time  estimates 
and  represents  a  value  for  which  there  is  an  approximate 
50  percent  chance  that  the  time  span  will,  in  fact,  prove 
to  be  shorter  and  a  50  percent  chance  that  the  time  span  will, 
in  fact,  prove  to  be  longer.  With  this  formula,  the  te  for 
Activity  1-2  is  calculated  using  the  time  estimates  shown 
along  the  activity  line  in  Figure  IV-1; 

6  +  (4x12)  +  30  =  84  =  14.0  ■  (te) 

6  6 

The  values  are  rounded  off  to  the  nearest  one-tenth  of  a 
week. 
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C.  Expected  Date  (T£) _ 

The  expected  date  (Tg)  for  each  event  is  the  date  that 
the  event  is  expected  to  occur.  It  is  calculated  by  adding 
to  the  date  of  each  start  event  or  completed  event  of  the 
network  the  activity  times  along  each  possible  path  up  to 
the  event  under  consideration.  The  latest  of  these  compu¬ 
ted  dates  is  the  expected  date  of  completion  for  the  event. 

In  the  sample  network  (Figure  IV-2)  there  is  one 
activity  leading  from  Event  1  to  Event  2  and  one  activity 
leading  from  E\e  nt  1  to  Event  3.  Therefore,  the  Tg's  for 
Events  2  (14.0).  and  3  (11.3)  are  the  same  as  the  te's  for 
the  activities  leading  to  the  events. 

Since  there  are  two  activities  (2-4  and  3-4)  leading  to 
Event  4,  there  are  two  values, and  the  larger  of  the  two  is 
selected  as  the  Te  for  Event  4.  The  te's  for  the  two  paths 
are  added  as  follows: 

.  For  Path  1  to  2  to  4,  add  14.0  and  21.2,  which 
equals  35.2. 

.  For  Path  1  to  3  to  4,  add  11.3  and  15.3,  which 
equals  26.6. 

The  larger  of  these  values,  35.2,  obtained  through  Event  2, 
becomes  the  Tfi  for  Event  4. 

Carrying  the  calculations  into  Event  5,  it  must  be 
remembered  that  although  there  are  two  activities  leading  to 
Event  5,  there  are  three  paths  leading  to  that  event  as  follows 

.  Path  1  -  Activities  1  to  2  to  4  to  5; 

.  Path  2  -  Activities  1  to  3  to  5; 

.  Path  3  -  Activities  1  to  3  to  4  to  5; 


The  expected  date  (TE)  is  a  calendar  date.  However,  in 
making  calculations  it  is  often  useful  to  make  use  of  an 
expected  time  which  is  a  numerical  value  for  the  expected 
date  equal  to  the  number  of  weeks  from  the  start  date 
to  the  expected  date.  In  the  following  discussions  of  TE 
and  Tl,  the  time  values  are  used. 
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TIME 

ESTIMATES 
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FIGURE  11-2  —  COMPUTATION  OF 


The  Te  for  Event  4  is  35.2  and  is  based  upon  the  longest 
path,  which  comes  via  Event  2  and  not  Event  3.  Therefore, 
in  computing  the  Te  for  Event  5,  it  is  obvious  that  the 
value  of  the  path  through  Events  3  and  4  is  less  than  the 
value  along  the  path  through  Events  2  and  4.  Consequently 
Path  3  above  need  not  be  computed.  Paths  1  and  2,  however, 
do  have  to  be  computed  as  follows: 

.  Path  1  -  Add  35.2  and  0.0,  which  equals  35.2; 

.  Path  2  -  Add  11.3  and  17.8,  which  equals  29.1. 

The  35.2  value  is  larger  than  29.1  and  therefore  becomes  the 
Te  for  Event  5. 

In  the  same  way,  TE's  are  obtained  for  each  event  in 
the  network  until  a  TE  of  66.0  weeks  is  obtained  for  Event  9, 
the  end  event.  This  value  of  66.0  weeks  after  program  start 
is  the  expected  time  for  program  completion.  The  TE's  for 
each  event  are  shewn  on  the  network  and  listed  in  the  table 
in  Figure  IV-2.  The  expected  time  for  each  event  is  con¬ 
verted  to  a  calendar  date  and  carried  as  such  after  a 
start  date  for  Event  1  has  been  established. 

D.  Latest  Allowable  Date  (TT.) 

The  latest  allowable  date  (TL)  is  the  latest  date  on 
which  an  event  can  occur  without  creating  an  expected  delay 
in  the  completion  of  the  program.  T^  is  found  by  calculating 
backward  from  the  end  event  of  a  network  to  the  start  event. 
To  determine  the  TL  for  an  event,  the  expected  elapsed  time 
(te)  for  an  activity  leading  from  that  event  is  subtracted 
from  the  TL  already  established  for  the  event  into  which 
the  activity  leads.  Where  an  event  has  several  activities 
leading  from  it,  the  subtraction  is  made  for  each  activity 
and  the  earliest  date  obtained  is  designated  as  the  Tjj  for 
that  event.  This  date  is  used  in  further  backward  compu¬ 
tations. 
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The  for  Events  7  and  8,  which  have  only  one  activity 
leading  from  each,  is  computed  as  follows: 


Previous  Event 


66,0  (Event  9) 
66.0  (Event  9) 


Minus  the  t 

$  f 

for  the  activi¬ 
ty  leading  into 
it 


Result  in  the  TL 
for  the  event 
from  which  the 
activity  leads 


8.8  =  57.2  (Tl  for  Event  8) 

9.2  =  56.8  (Tl  for  Event  7 


The  Tl  for  Event  5,  which  has  two  activities  leading 
from  it,  is  computed  as  follows: 


Previous  True  TL  Minus  the  t„ 


Equals  Tt  for  Event  5 


66.0  (Event  9)  -  30.8 

56.8  (Event  7)  -  14.0 


35.2 

42.8 


Since  there  are  two  possible  T^’s  for  Event  5,  the 
smallest  value  is  selected;  therefore  the  value  of  35.2 
is  the  T^  for  Event  5.  The  complete  calculation  of  TL  for 
the  events  is  shown  in  Figure  IV-3. 


E.  Slack  (TL  -  TE) 


In  computing  slack  for  the  sample  network,  T^  was 
made  equal  to  TE  for  the  end  event.  When  this  condition 
exists  there  is  zero  slack.  Since  the  TE's  and  the  T^'s 
are  marked  on  the  network  in  Figure  IV-3,  they  are  easy 
to  compare  and  it  can  be  seen  that  TE  equals  TL  for  Events 
9,5,4  and  2.  Therefore,  these  events  have  zero  slack. 

Slack  for  the  other  events  is  determined  by  subtracting 
TE  from  T^  .  Slack  of  Event  8  is  27.2  (57.2  -  30.0),  and 
for  Event  7  it  is  7.6  (56.8  -  49.2).  This  process  is  con¬ 
tinued  until  the  slack  for  each  event  is  obtained  and  is 
listed  in  the  table  in  Figure  IV-3. 

F.  Critical  Path 


The  final  step  is  an  identification  of  the  critical 
path.  The  critical  path  of  a  network  is  that  path  which 
is  the  most  time  consuming.  Events  having  the  least  slack 
lie  on  the  critical  path.  In  the  example,  the  least  slack 
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FIGURE  11-3 —  COMPUTATION  OF  TL  AND  SLACK 


is  zero;  therefore,  the  critical  or  longest  path  consists 
of  Activities  1-2-4-5-9.  The  network  for  a  large  and  com¬ 
plex  system  will  probably  have  several  paths  having  equal 
or  approximately  equal  slack.  In  this  example,  the  second 
most  critical  path  (Activities  1-3-5-9)  has  a  6.1-week  posi¬ 
tive  slack,  and  the  third  most  critical  path  (Activities 
1-2-4- 5-7-9)  has  a  7.6-week  positive  slack.  Although  these 
paths  are  not  critical  at  this  time,  the  manager  must  be 
aware  that  a  path  may  slip  more  than  the  difference  in  slack 
between  it  and  the  critical  path,  thereby  becoming  the  new 
critical  path. 

The  critical  path  may  be  outlined  on  the  network 
drawing  in  color,  or  where  reproduction  is  required,  a 
double  or  heavier  line  may  be  drawn.  Less  critical  paths 
may  be  shown  in  various  other  colors  or  patterns  for  better 
graphical  presentation. 

G.  Derivation  of  the  Expected  Elapsed  Time  (te)  and  the 
Standard  Deviation  (<r)  from  the  Three  Time  Estimates 

The  expected  elapsed  time  (te)was  introduced  as  a 
statistically  weighted  average  of  the  three  time  estimates 
which  could  be  expressed  by  the  simple  equation 

te  =  a  +  4m  +  b 
6 

This  expression  rests  on  the  assumption  that  the  expected 
activity  time  is  best  represented  by  a  distribution  of 
values.  In  particular,  the  beta  distribution  is  used  as 
the  model  of  this  distribution  of  activity  time  values. 

The  node  of  this  curve  is  located  at  the  most  likely  time 
and  its  range  is  the  interval  between  the  optimistic  and 
pessimistic  times,  as  illustrated  below. 
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The  two  important  parameters  to  be  derived  from  this 
distribution  are  the  expected  (or  mean)  elapsed  time  and 
the  standard  deviation. 

For  a  certain  class  of  frequency  distributions,  of 
which  the  beta  is  one,  the  standard  deviation  can  be 
estimated  as  one-sixth  of  the  range.  Therefore,  the 
standard  deviation  of  an  activity's  expected  elapsed 
time  is  expressed  by  the  equation 


<j  = 


b-a 

6 


To  derive  the  expected  time,  the  probability  density 
function  of  the  distribution  is  expressed,  straight¬ 
forward  calculations  are  performed,  and  a  linear  approxi¬ 
mation  is  made,  resulting  in  the  equation 


te  =  a  +  4m  +  b 
6 


The  standard  deviation,  sigma  (o-) ,  is  a  measure 
of  variation  about  the  mean  of  a  distribution. 
Its  numerical  value  is  such  that  67  percent 
of  the  values  making  up  the  distribution  will 
be  within  one  sigma  of  the  mean  value,  95 
percent  of  the  values  will  be  within  two 
sigma  of  the  mean  value,  and  99  percent, 
within  three  sigma. 
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The  figure  below  shows  a  beta  distribution  for  three 
estimates  of  5,  7,  and  15  weeks  corresponding  respectively 
to  the  optimistic  (a),  most  likely  (m) ,  and  pessimistic  (b) , 
time  estimates.  From  a,  m,  and  b  the  expected  elapsed  time 
of  8  weeks  is  derived,  i.e. 


te  =  5  +  (4) (7)  +  15  =  8 
6 


This  value  of  eight  weeks  is  the  mean  of  the  distribition 
and  divides  the  area  under  the  curve  in  half.  Thus,  there 
is  an  estimated  50-percent  chance  that  the  time  span  will, 
in  fact,  prove  to  be  shorter  than  8  weeks  and  a  50-percent 
chance  that  the  time  span  will,  in  fact,  prove  to  be  longer. 

The  standard  deviation  is  1.7  weeks,  i.e. 

*  =  b  -  a  =  15-5  =1.7 
6  6 

Thus,  there  is  a  .99  probability  that  the  actual  elapsed 
time  will  fall  within  8  -  5.1  weeks  or  between  2.9  and  13.1 
weeks. 

When  the  values  of  te  and  cr  have  been  derived  for  all 
the  activities  in  the  network,  the  probability  that  the  end 
event  of  the  program  will  be  completed  by  some  scheduled  or 
desired  date  can  be  calculated.  This  calculation  is  demon¬ 
strated  in  Chapter  XII,  Program  Analysis. 
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NETWORK  SUMMARIZATION  AND  INTEGRATION 
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NETWORK  SUMMARIZATION  AND  INTEGRATION 


In  large  programs,  detailed  networks  will  be  generated 
by  several  agencies.  These  networks  will  be  constructed  to 
the  depth  of  detail  necessary  for  control  at  the  operating 
level  and  generally  will  contain  more  detail  than  required 
by  middle  and  top  management.  A  technique  has  been  devel¬ 
oped  whereby  a  detailed  network  can  be  summarized  to  a 
level  appropriate  for  the  higher  levels  of  management. 
Likewise,  the  technique  facilitates  the  integration  of  a 
number  of  summarized  networks  for  the  appraisal  of  an  over¬ 
all  program.  The  summarization  technique  and  integration 
procedure  require  that  certain  rules  be  followed  in  handling 
the  events  that  must  be  included  in  a  summarized  network  and 
the  events  that  are  common  to  several  networks  in  order  that 
integration  may  be  accomplished.  These  requirements  are 
described  in  the  following  paragraphs. 

A.  Interface  Events 


One  of  the  key  elements  in  the  summarization  technique 
is  the  interface  event.  Interface  events  are  those  that 
signal  the  necessary  transfer  of  responsibility,  end  items, 
or  information  from  one  part  of  the  effort  to  another.  As 
there  are  several  agencies  involved  in  a  weapon  system  de¬ 
velopment  and  each  agency's  detailed  network  is  not  always 
independent  of  the  others,  interface  events  will  exist. 
These  events  will  appear  and  retain  their  identity  in  the 
detailed,  summarized  and  integrated  networks. 

Interface  events  may  appear  as  either  start,  end,  or 
regular  events  in  the  body  of  the  network.  Since  Tg  and 
Tl,  as  computed  for  interface  events  in  the  processing  of 
the  integrated  network,  must  be  accepted  as  valid  dates  by 
the  detailed  networks,  processing  is  more  convenient  if  the 
interface  events  appear  as  start  or  end  events;  otherwise, 
the  process  must  have  the  capability  to  fix  firmly  the  Tg 
and  T l  values  so  that  they  are  not  affected  by  subsequent 
internal  processing  of  detailed  networks. 
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B.  Network  Summarization 


The  summarization  technique  is  a  process  of  reducing 
detailed  networks  to  a  skeletal  or  summary  network  for  sim¬ 
plification  in  the  integration  cycle.  Each  reporting  or¬ 
ganization,  as  required,  will  prepare  and  submit  summarized 
network  data  to  the  organization  responsible  for  integrating 
the  summarized  networks  into  a  total  system  network.  The 
summarized  network  may  be  constructed  manually  or  mechan¬ 
ically,  depending  upon  the  capabilities  of  the  reporting 
organization. 

The  summarized  network  will  contain  the  following 
events:  start,  end,  interface,  milestone,  and  those  selec¬ 

ted  by  the  summary  technique  from  the  detailed  networks. 

Each  constraint  in  the  summarized  network  represents  the 
longest  path  from  one  event  to  the  next.  The  corresponding 
te  values  represent  the  summation  of  the  te  values  along  the 
longest  path  as  derived  from  the  detailed  network.  The  TE 
and  Tl  for  the  events  appearing  in  the  summarized  network 
equal  the  Te  and  Tl  computed  for  these  events  in  the  detailed 
networks.  Figure  V-l  illustrates  the  general  concept  of 
summarized  networks. 

Designated  events  are  identified  by  level  codes.  The 
summarizing  program  then  considers  every  possible  pair  of 
these  events  and  determines  whether  or  not  a  topological 
relationship  between  the  two  events  exists  (i.e.,  at  least 
one  path  passes  through  both  events) .  If  such  a  relation¬ 
ship  exists,  then  a  constraint  between  the  two  events  is 
calculated  for  the  summarized  network,  and  the  expected 
elapsed  times  are  derived  from  the  longest  path  between  the 
two  events.  The  optimistic  and  pessimistic  time  values  for 
each  such  constraint  are  established  at  three  standard  de¬ 
viations  each  side  of  the  calculated  te. 

The  constraints  obtained  in  this  manner  are  sufficient 
to  describe  the  full  effect  of  the  detailed  activities. 

It  should  be  noted  that  the  summarizing  program  does 
not  initially  determine  expected  or  latest  dates  or  any  of 
the  other  standard  PERT  calculations.  It  simply  produces 
a  file  of  the  constraints  in  the  summarized  network  along 
with  their  time  estimates  and  other  information.  This  con¬ 
straint  file  along  with  similar  files  from  other  detailed 
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FIGURE  I-l  —GUIDANCE  NETWORK 


networks  and/or  detailed  network  files  then  form  input  for 
a  network  integration  process. 

C .  Network  Integration 

Network  integration  is  a  process  of  combining  all  sub¬ 
networks  into  a  total  program  network.  The  input  data  for 
the  program  network,  as  described  above,  may  be  derived 
from  summarized  networks  and/or  detailed  networks. 

Each  reporting  agency  will  submit  its  required  network 
data  with  expected  elapsed  times  (te)  to  the  Designated  Pro 
cessing  Agency  (DP A)  for  maintaining  and  processing  the  pro 
gram  network.  This  integrated  network  will  provide  am  over 
view  of  total  system  progress  amd  allow  observamce  of  the 
interrelationships  and  impacts  among  the  various  agencies 
involved  in  the  system  development.  The  event  Tg  amd  Tl 
dates,  obtained  by  processing  the  integrated  network,  will 
provide  information  for  evaluating  the  planned  or  contrac¬ 
tually  scheduled  dates  for  major  milestones  and  interface 
events.  When  the  integrated  network  expected  dates  show 
that  amy  of  the  scheduled  dates  are  unrealistic,  the  pro¬ 
gram  manager  may  desire  to  negotiate  a  change  of  these 
scheduled  dates. 

Figures  V-2  amd  V-3  show  two  more  examples  of  network 
summarization.  Figure  V-4  is  the  network  resulting  from 
the  initial  integration  of  the  three  summarized  networks. 
The  impact  of  the  integrated  network  calculations  on  the 
original  networks  is  as  follows: 

.  The  critical  path  of  the  integrated  network 
has  chamged  significantly  from  the  critical 
paths  of  each  individual  network.  The  path 
now  starts  in  the  Guidance  Network,  drops 
to  the  Re-entry  Vehicle  Network,  amd  then 
moves  to  the  Airframe  Network. 

.  The  latest  allowable  date  (TL)  for  Interface 
Event  70-003-007  was  computed  to  be  26  Aug  63 
in  the  Guidance  network,  24  July  63  in  the 
Airframe  network,  and  21  May  63  in  the  Re-entry 
network.  However,  it  is  seen  from  the  inte¬ 
grated  network  that  the  true  TL  for  this  event 
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FIGURE  1-2  —  AIRFRAME  NETWORK 


FIGURE  1-3  —  RE-ENTRY  NETWORK 


FIGURE  1-4  —  INTEGRATED  NETWORK 


is  18  April  63.  Thus,  new  and  more  re¬ 
straining  Tl's  have  resulted  for  Event 
70-003-007  and  its  predecessor  events  in 
each  summarized  network. 

.  Slack  originally  computed  along  the  critical 
path  in  the  Guidance  network  was  6.6  weeks 
negative,  in  the  Airframe  network  6.7  weeks 
negative,  and  in  the  Re-entry  Vehicle  net¬ 
work  9.9  weeks  negative.  Slack  computed 
along  the  critical  path  in  the  integrated 
network,  however,  is  24.6  weeks  negative. 

.  The  three  networks'  start  event.  Program 
Start  (70-000-001),  was  originally  scheduled 
for  14  Nov  62  with  the  end  event  of  the  pro¬ 
gram,  Test  Vehicle  on  Dock  (70-002-051)  in 
the  Airframe  network,  scheduled  for  15  June 
64.  After  the  integration,  it  is  seen  that 
the  program  requires  24.6  weeks  more  time  than 
is  available  between  the  scheduled  program 
start  and  finish  dates,  indicating  that  the 
program  should  actually  have  started  almost 
six  months  earlier  than  planned  in  order  to 
meet  the  present  schedule.  Since  this 
earlier  date  has  passed,  a  change  in  either 
the  plan  or  resource  appDication  must  be  made 
if  the  scheduled  completion  date  is  to  be  met. 

D.  Controlled  Events 


In  establishing  and  maintaining  the  integrated  network, 
a  method  of  identifying  and  defining  the  interface  events 
and  significant  milestones  must  be  established.  An  event 
coordination  process  has  been  developed  for  the  selection, 
recording,  coordination,  and  storage  of  those  events  which 
define  and  interrelate  the  overall  system.  (A  detailed 
description  of  this  event  coordination  process  is  given  in 
Appendix  C.  Figure  C-l  illustrates  the  process.)  Specific 
data  for  these  events  is  collected  by  the  integrating  agency 
and  maintained  in  a  Controlled  Event  Data  File.  Events 
selected  from  this  file,  with  program  manager  approval,  make 
up  the  Controlled  Event  Log.  This  log  is  issued  by  the  DPA 
to  all  participating  organizations  and  serves  to  identify 
those  events  which  must  appear  in  each  organization's 
summarized  network. 
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The  event  originator  or  performing  agency  has  prime 
responsibility  for  controlled  event  identification,  des¬ 
cription,  and  numbering.  Each  user  of  an  interface  event 
is  responsible  for  notifying  the  originator  of  his  intended 
use  and  of  his  agreement  or  disagreement  with  the  interface 
event  data.  The  DPA  maintains  a  data  file  and  produces  the 
controlled  event  data  reports. 
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PERT  TIME  SYSTEM  OPERATION 


Chapters  II  through  V  describe  the  basic  concepts  and 
the  mechanics  of  the  PERT  TIME  System  without  relating  these 
techniques  to  the  operation  of  the  system.  These  techniques 
and  procedures  are  related  to  the  application  and  operation 
of  PERT  TIME  in  Chapters  VI  through  XIII. 

The  entire  system  is  introduced  in  this  chapter  in  order 
to  provide  a  framework  or  perspective  for  greater  understand¬ 
ing  of  the  succeeding  material. 

A.  System  Phases 


The  PERT  TIME  System  Cycle  involves  two  distinct  phases, 
a  Planning  Phase  during  which  a  master  time  plan  expressed  in 
network  form  and  a  program  schedule  are  developed,  and  an 
Operating  Phase  during  which  program  progress  is  assessed  and 
the  impact  of  accomplishment  on  future  plans  is  forecast.  An 
illustration  of  the  overall  cycle  is  shown  in  Figure  VI-1. 

A  more  definitive  relationship  of  the  two  phases  within  this 
overall  cycle  is  illustrated  in  Figure  VI-2.  The  interaction 
between  government  and  industry  occurring  within  the  cycle  is 
illustrated  in  the  data  flow  of  Figure  VI-3. 

Ideally,  the  whole  program  is  planned,  the  plan  is  ap¬ 
proved,  work  is  authorized,  and  the  operating  phase  of  meas¬ 
uring,  processing,  analyzing,  and  decision-making  begins.  In 
actual  practice,  however,  a  plan  is  developed  and  approved  for 
part  of  the  program;  this  particular  plan  then  commences 
while  some  other  parts  of  the  program  are  still  being  planned. 
Also,  the  Planning  Phase  is  repeated  in  part  for  portions  of 
the  program  that  have  been  in  process  where,  because  of  some 
significant  deviation  from  plan,  management  has  adopted  some 
alternative  course  of  action.  Consequently,  planning  tends 
to  continue  throughout  the  life  of  the  program. 

The  Operating  Phase  on  the  other  hand  takes  place 
regularly  and  frequently  (typically,  every  two  weeks) . 

A  summary  of  the  elements  of  these  phases  is  presented 
below. 
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FIGURE  H-I-PERT  TIME  SYSTEM  CYCLE 
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FIGURE  H-2  —  PLANNING  AND  OPERATING  PHASES 
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OPERATING  PHASE 


B.  The  Planning  Phase 


1 .  Establishing  Program  Objectives 

Planning  originates  with  the  careful  definition  of  what 
has  to  be  accomplished,  i.e.,  delineation  of  the  end  items 
of  the  program.^  These  end  items  can  be  identified  by  sub¬ 
dividing  the  total  system  into  its  component  end  items  and 
successively  dividing  each  of  these  end  items  into  their 
component  parts.  Such  a  process  will  generate  a  program 
"work  breakdown  structure”  as  shown  in  Figure  VII-1,  Chapter 
VII.  This  work  breakdown  structure  will  then  serve  as  the 
framework  for  schedule  planning  and  monitoring  (and  more 
generally,  it  will  serve  as  the  framework  for  planning  and 
monitoring  all  aspects  of  the  program) . 

2 •  Developing  the  Plan 

Once  the  end  items  of  the  program  have  been  defined, 
the  major  interim  achievements  or  milestones  in  the  accom¬ 
plishment  of  these  end  items  must  be  identified.  The  se¬ 
quencing  of  these  milestones  provides  a  time-phased  frame¬ 
work  within  which  the  network  plan  and  subsequently  schedule 
are  developed. 

Guided  by  the  work  breakdown  structure  and  the  major 
milestones,  a  PERT  network  representing  the  plan  for  the 
accomplishment  of  the  program  is  constructed.  The  network 
for  the  total  system  acquisition  plan  may  be  developed  at 
once  or  the  network  may  be  developed  a  portion  at  a  time  as 
needed  and  feasible. 

Time  estimates  are  made  for  each  activity  in  the  net¬ 
work  assuming  a  normal  level  of  resource  availability  during 
a  normal  work  period.  These  time  estimates  are  fed  into  the 


The  term  "end  item"  represents  hardware,  services, 
equipment,  or  facilities  that  are  deliverable  to  the 
customer  or  that  constitute  a  commitment  on  the  part 
of  the  contractor. 
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data  processing  system  which  calculates  te,  Tg,  Tg,  and  slack, 
identifies  the  critical  path,  and  expresses  the  network  plan 
in  calendar  dates  thereby  enabling  comparison  with  the  pro¬ 
gram's  gross  schedule  requirements. 

Usually  the  initial  time  plan  does  not  conform  suffi¬ 
ciently  to  the  directed  or  desired  completion  dates.  Under 
these  circumstances,  a  replanning  process  is  initiated, 
resulting  in  new  time  estimates  and  new  completion  dates. 

This  cycle  is  repeated  until  sufficient  conformity  with 
desired  dates  is  obtained. 

3 .  Establishing  Schedules 

The  resultant  network  plan  will  not,  generally,  pro¬ 
vide  a  schedule  for  the  work  to  be  done.  This  is  true  because 
the  time  estimates,  made  irrespective  of  calendar  dates  and 
based  on  normal  working  conditions,  do  not  take  into  account 
the  availability  of  resources  (manpower,  equipment,  facili¬ 
ties,  and  funding)  during  specific  calendar  time  periods 
and  because  they  may  not  have  allowed  for  the  manager's 
judgment  of  a  reasonable  time  for  performing  the  work.  Hence 
the  network  plan  must  be  translated  into  a  timetable  with 
specific  calendar  dates,  which  will  govern  the  start  and 
completion  of  work  and  authorize  the  expenditure  of  resources. 
This  translation  process  will  be  controlled  by  the  availa¬ 
bility  of  resources  and  the  manager's  judgment. 

When  a  satisfactory  schedule  backed  up  by  a  consistent 
network  plan  has  been  developed,  approval  is  given  and  work 
may  be  authorized. 

C.  The  Operating  Phase 

The  Operating  Phase  begins  with  the  authorization  of 
the  work  to  be  performed  under  that  part  of  the  program  for 
which  a  schedule  has  been  established  and  approved. 

1.  Preparing  Input  Data 

During  the  Operating  Phase,  the  following  information 
is  reported: 
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.  completed  activities  and  their  completion 
date; 

.  changes  in  activity  time  estimates; 

.  changes  in  schedule; 

.  event  and  activity  additions  or 
deletions . 

This  data  is  prepared  in  computer  input  format  and  sent  to 
the  Designated  Processing  Agency. 

2 .  Processing  the  Input  Data 

This  input  data  will  be  processed  to  produce  the 
desired  PERT  output  reports.  In  all  but  small  PERT 
applications  a  computer  will  be  used  to  accomplish  this 
processing.  Specifically  in  the  USAP  PERT  TIME  System, 
the  USAP  PERT  TIME  program  will  be  utilized. 

3.  Preparing  Reports 

From  the  data  processing  system  a  number  of  output 
reports  displaying  current  and  forecasted  status  will  be 
produced  for  analysis  and  evaluation. 

4.  Analyzing  Reports 

The  computer  output  reports  and  perhaps  special 
purpose  reports  derived  from  the  computer  outputs  will 
be  analyzed  to  aid  in  determining; 

.  what  the  problems  are; 

.  where  management  action  is  needed; 

.  what  the  alternative  courses  of  action 
are;  and 

.  the  best  course  of  action. 
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5.  Management  Action 


Using  the  results  of  the  analysis,  management  makes 
decisions  and  takes  action  to  correct  the  problem.  Normally, 
this  results  in  an  updating  of  the  input  data  to  reflect  the 
action  taken.  However,  this  action  may  involve  rescheduling, 
replanning  or  in  some  instances,  reprogramming.  Where  alter¬ 
native  courses  of  action  are  contemplated,  simulation  pro¬ 
vides  a  means  for  evaluating  the  impact  of  these  alternatives. 
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DEVELOPMENT  OF  THE  PLAN 


In  the  previous  chapter,  the  elements  of  the  planning 
phase  were  enumerated  and  briefly  discussed.  There  are  two 
primary  end  products  resulting  from  the  performance  of  these 
steps:  the  master  time  plan,  expressed  in  network  form,  and 

the  program  schedule,  based  on  the  time  plan.  This  chapter 
expands  on  the  development  of  the  plan.  The  succeeding 
chapter  treats  the  scheduling  process. 

A.  Identification  of  Objectives 

Development  of  the  plan  begins  with  the  identification 
of  the  objectives  of  the  program.  Before  work  on  the  pro¬ 
gram  begins  the  following  steps  should  be  accomplished? 

.  the  prime  objectives  must  be  carefully 
determined  and  defined; 

.  the  supporting  objectives  leading  to  the 
attainment  of  each  prime  objective  must  be 
carefully  determined  and  defined; 

.  the  objectives  must  be  organized  and  inter¬ 
related  to  enable  attainment  of  overall 
program  objectives;  and 

.  these  objectives  must  be  communicated 
effectively  to  operating  management  in 
the  next  lower  levels  of  the  organization. 

B.  Program  Work  Breakdown  Structure 

As  the  objectives  are  developed  in  greater  detail  they 
form  the  program  work  breakdown  structure  which  establishes 
a  common  framework  for  the  accomplishment  of  all  the  work 
to  be  performed.  It  provides  a  basis  for  uniform  planning 
and  program  visibility,  enables  assignment  of  responsibili¬ 
ties,  and  delineates  objectives  for  monitoring  progress. 
Additionally,  it  establishes  the  basis  for  constructing 
networks  at  any  desired  level  of  detail  by  identifying  the 
end  items  to  be  accomplished  at  that  level. 
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The  work  breakdown  structure  is  developed  downward 
by  proceeding  from  the  major  program  end  items  (hardware, 
services,  equipment,  or  facilities)  to  successively  lower 
levels,  until  manageable  units  for  planning  and  control  are 
derived,  A  top-down  approach  is  used  to  guide  planning 
rather  than  allowing  detailed  plans  to  be  generated  outside 
of  a  common  framework.  It  is  apparent  that  networks  can 
readily  be  constructed  without  the  use  of  a  work  breakdown 
structure,  but  quite  possibly  such  networks  will  be  incom¬ 
plete  or  inconsistent  with  program  objectives. 

Briefly,  the  work  breakdown  structure  establishes 
the  basTs  for: 

.  defining  the  work  to  be  performed  in 
successively  greater  detail; 

.  determining  how  the  various  end  items  of 
work  are  related  to  one  another; 

.  constructing  networks  at  any  desired  level 
of  detail; 

.  identifying  the  organizational  element (s) 
responsible  for  accomplishing  the  work 
at  each  successive  level  of  work  definition; 

.  summarizing  actual  status  and  forecasted 
progress  of  the  program  for  progressively 
higher  levels  of  management. 

A  partial  work  breakdown  structure  is  shown  in  Figure  VII-1. 
A  complete  work  breakdown  structure  is  shown  in  Appendix  A. 

C.  Identifying  Major  Milestones 

Once  the  objectives  have  been  defined  the  means  of 
attaining  these  objectives  must  be  laid  out.  Specifically, 
a  plan,  depicted  by  a  PERT  network,  is  evolved.  The  first 
step  in  this  process  is  the  identification  and  selection 
of  the  major  milestones  of  the  program.  Many  of  these  may 
already  have  been  established  by  earlier  and  higher  level 
planning  processes.  However,  additional  major  milestones, 
peculiar  to  the  particular  program,  will  also  have  to  be 
identified.  Once  identified,  the  milestones  must  be  care¬ 
fully  defined.  With  the  work  breakdown  structure,  these 
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FIGURE  HH-  PROGRAM  WORK  BREAKDOWN  STRUCTURE 
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milestones  will  then  serve  as  the  base  for  the  development 
of  the  networks,  and  additionally  they  will  provide  anchor 
points  for  the  establishment  of  schedules.  It  might  be 
considered  that  the  work  breakdown  structure  is  a  vertical 
framework  for  the  networks,  identifying  the  program  objec¬ 
tives  in  the  form  of  end  items  at  all  levels  of  detail, 
while  a  sequenced  array  of  major  milestones  constitutes  a 
horizontal  framework  for  the  networks,  identifying  the 
time-phased  plan  for  the  attainment  of  these  objectives. 

The  milestones  adopted  should  include  not  only  those 
depicting  the  progress  of  the  design  and  hardware  but  also 
key  management  decision  or  action  events  and  the  major 
logistic  events  involved  in  bringing  the  system  to  an  opera¬ 
tional  status. 

D.  Development  of  the  Plan  in  Network  Form 

The  network  must  be  developed  as  a  valid  depiction  of 
the  program  plan,  suitable  for  use  in  the  actual  management 
of  the  program.  If  the  network  does  not  accurately  repre¬ 
sent  the  program,  serious  errors  may  result.  In  making 
the  network  plan  valid,  the  manager  himself  must  undoubtedly 
become  involved. 

The  development  of  the  PERT  network  is  inseparable  from 
the  function  of  planning  as  understood  by  management.  Per¬ 
haps  the  single  most  significant  statement  to  be  made  re¬ 
garding  the  development  of  the  PERT  network  is  that  it  must 
be  created  by  personnel  in  the  manager's  organization  who 
are  normally  responsible  to  him  for  performance  of  the 
program  planning  function.  Until  these  planners  become 
skilled  in  the  development,  use,  and  maintenance  of  PERT, 
they  may  require  the  assistance  of  PERT  specialists  in 
the  creation  of  new  or  revised  networks.  All  participants 
must  have  a  common  understanding  of  the  objectives  to  be 
reached. 

If  responsibilities  are  clearly  assigned  to  these 
personnel,  the  network  will  be  more  complete  and  accurate 
than  plans  prepared  in  other  forms  and  formats.  Program 
planning  personnel  must  plan  in  detail  to  effect  the 
development  of  the  program  plan  in  the  form  of  PERT  networks. 
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The  development  of  the  network  materially  improves 
performance  of  the  planning  function.  This  function  on 
a  large,  complex  program  is  demanding.  The  logical  and 
systematic  thought  processes  reguired  of  planners  in  the 
construction  of  the  PERT  network  inevitably  deepens  under¬ 
standing  of  the  objectives  of  a  project  and  of  the  work  to 
be  performed. 

1 .  Program  Management  Network 

A  network  reflecting  the  total  system  acquisition  plan 
is  called  the  Program  Management  Network.  This  network,  in 
preliminary  form,  is  initially  prepared  by  the  Program 
Director's  Office  as  part  of  the  precontractual  planning 
effort.  Later  in  the  negotiation  and  early  contractual 
phases,  the  network  is  refined  through  the  assistance  of 
other  Air  Force  and  government  agencies  and  the  contractors 
involved,  and  becomes  the  operating  version  of  the  network 
for  both  planning  and  control  purposes. 

There  are  two  versions  of  the  Program  Management  Net¬ 
work.  The  first,  known  as  the  Preliminary  Program  Management 
Network,  is  drawn  "in-house"  at  the  beginning  of  the  program 
as  a  planning  network  to  use  for: 

.  the  preparation  of  the  program  plan,  the  work 
statement,  and  the  Request  for  Proposal; 

.  the  evaluation  and  source  selection  period;  and 

.  the  conveying  of  key  events  to  the  contractor 
for  his  guidance  in  preparing  detailed  networks. 

The  second, known  as  the  Operating  Program  Management  Network, 
is  developed  in  conjunction  with  all  participating  organiza¬ 
tions  after  award  of  contracts. 

The  Program  Management  Network  is  a  generalized  or 
simplified  network,  yet  it  must  contain  the  level  of  detail 
required  by  the  Program  Director  for  overall  planning  and 
control  of  the  entire  program.  When  properly  constructed, 
this  single  network  should  enable  the  Program  Director's 
staff  to  survey  the  entire  program  and  quickly  ascertain 
the  critical  areas  insofar  as  milestones  and  schedules  are 
concerned.  The  Program  Management  Networks  are  essentially 
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event-and-date-oriented  (i.e.,  concerned  with  identifying 
and  tying  together  all  the  major  milestones  of  the  program 
and  the  related  schedules) . 

Both  types  of  the  Program  Management  Network  must 
include  the  significant  milestones  in  the  program  as 
determined  and  prescribed  by  the  Program  Director.  These 
mandatory  milestones  must  be  augmented  by  other  events 
representing  additional,  but  less  significant,  milestones 
as  well  as  by  the  interfaces  and  constraining  events  that 
reflect  the  inputs  of  the  various  contributors  to  the 
program.  Thus,  a  network  is  evolved  that  ties  together 
all  the  major  segments  of  the  program. 

Figure  VII-2  illustrates  the  general  concept  of 
developing  an  Operating  Program  Management  Network.  Each 
contractor  and  government  agency  prepares  a  detailed  net¬ 
work  representing  his  area  of  responsibility.  The  subse¬ 
quent  integration  of  these  segments  produces  the  Operating 
Program  Management  Network.  Actual  development  of  the 
operating  version  of  the  network  for  control  purposes  (as 
differentiated  from  the  network  initially  developed  pri¬ 
marily  for  planning  purposes)  will  be  accomplished  by 
the  cooperative  effort  of  all  concerned  under  the  guidance 
of  the  Program  Director. 

2.  Detailed  Networks 

Each  contractor  and  supporting  governmental  agency 
involved  will  construct  a  detailed  network  or  networks  in 
accordance  with  the  requirements  of  the  Program  Director 
and  based  on  the  work  breakdown  structure.  The  detailed 
networks  are  drawn  within  the  framework  of  the  Preliminary 
Program  Management  Network  and  the  work  breakdown  structure. 

As  unplanned  efforts  are  discovered  during  detailed  net¬ 
working,  the  program  breakdown  and  ultimately  the  Program 
Management  Network  are  modified  to  reflect  these  changes. 

A  top-down  approach  is  used  to  guide  detailed  planning 
rather  than  allowing  detailed  plans  to  be  generated  out¬ 
side  of  a  common  framework.  Significant  data  from  the 
detailed  networks  are  carried  upward  to  the  Program  Manage¬ 
ment  Network,  Thus,  while  the  detailed  networks  are  an 
operating  tool  under  the  immediate  control  of  the  organiza¬ 
tion  responsible  for  doing  the  work,  their  status  is  displayed 
on  the  Program  Management  Network. 
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FIGURE  SH-2— DEVELOPMENT  OF  THE  OPERATING  PROGRAM 
MANAGEMENT  NETWORK 
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It  is  important  that  detail  be  kept  to  a  level  that 
will  enable  the  network  data  to  be  computed  and  analyzed. 

Too  much  detail  in  the  initial  network  delays  the  first 
analysis  of  the  network.  After  an  initial  analysis  is 
made,  more  detail  can  readily  be  added. 

It  is  not  necessary,  however,  or  even  recommended, 
that  the  degree  of  detail  in  the  network  be  the  same  for 
all  parts  of  the  network.  For  instance,  that  portion  of  the 
plan  in  the  near  future  should  be  maintained  in  more  detail 
than  the  portions  of  the  plan  farther  out.  As  time  passes, 
more  detail  is  added  gradually  to  the  near-term  portions  of 
the  network.  This  is  a  natural  method,  since  most  plans  are 
continually  refined  as  more  becomes  known  about  the  current 
results  and  their  effect  on  the  future  course  of  action. 
Another  recommended  practice  is  to  maintain  more  detail  on 
the  most  critical  areas  of  the  program  (where  they  are  known} 
However,  the  pitfall  of  grossly  slighting  apparently  straight¬ 
forward  or  ancillary  functions  must  be  avoided  as  any  part 
of  the  program  can  become  critical. 

In  general,  however,  the  network  should  be  established 
to  the  level  of  detail  needed  to  exercise  management  control. 
As  the  program  progresses,  the  network  will  require  revision 
to  reflect  unforeseen  dependencies  and  tasks,  and  changes  to 
the  program  as  well  as  more  or  less  detail. 

To  be  realistic  and  comprehensive,  the  network  should 
be  developed  by  those  personnel  responsible  for  accom¬ 
plishment  of  the  tasks  being  networked  and  by  personnel 
familiar  with  networking  techniques. 

3.  Making  the  Time  Estimates 

Time  estimates  must  be  made  for  each  activity  in  the 
network.  These  time  values  should  not  initially  be  consi¬ 
dered  in  terms  of  calendar  date,  but  rather  as  flow  time. 

Any  identification  with  preset  calendar  dates  is  to  be 
avoided,  for  it  nullifies  one  of  the  major  advantages  of 
the  use  of  the  network. 

Time  estimates  should  be  made  by  personnel  most 
familiar  with  individual  activities.  The  quality  of  the 
time  estimates  will  depend  on  their  background  and  under¬ 
standing  of  the  work  to  be  performed  as  well  as  the  capa¬ 
bility  of  the  interviewers  who  are  collecting  the  data. 
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4.  Refinement  of  the  Plan 


Once  the  time  estimates  for  each  activity  have  been 
obtained,  the  first  data  processing  run  can  be  made. 

From  these  estimates,  the  expected  dates,  the  latest  allow¬ 
able  dates,  slack  and  the  critical  path  are  determined. 

From  this  data,  the  feasibility  of  the  plan  can  be 
judged.  Usually  the  results  of  the  first  run  will  not  be 
satisfactory  and  a  revision  of  the  plan  must  be  generated. 
Activity  times  cannot,  of  course,  be  shortened  arbitrarily. 
Alternatives  for  shortening  the  planned  time  for  the  pro¬ 
gram  are: 

,  alteration  of  the  network  by  introducing 
greater  concurrency  of  effort; 

.  loading  of  resources  on  limiting  activities; 

.  change  in  performance  requirements; 

.  balance  of  the  plan  by  reallocating  resources 
among  activities. 

Following  this  analysis  and  replanning  process,  new 
time  estimates  are  made  and  processed  and  the  data  is  once 
more  prepared  for  analysis.  The  cycle  is  repeated  until 
sufficient  conformity  with  directed  or  desired  dates  is 
obtained. 

5.  Approving  the  Plan 

When  the  establishment  of  the  program  work  breakdown 
structure  and  the  construction  of  the  network  have  been 
completed,  the  Program  Director  will  review  the  entire  sys¬ 
tem.  The  purpose  of  the  review  is  to  insure  that  the  data 
to  be  presented  will  be  understandable,  meaningful,  and 
reliable.  The  Program  Director  must  be  convinced  that  the 
formal  plans  and  procedures  established  and  employed  by 
the  contractor  will  start  at  the  bottom  of  the  work 
breakdown  structure  and  be  realistically  summarized. 
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6.  PERT  Planning  Standards 


The  plan  must  meet  certain  fundamental  standards  which 
are  stated  below. 

The  work  breakdown  structure  and  the  network (s)  must: 

.  outline  the  complete,  current  plan,  which 
in  terms  of  activities  and  events,  indicates 
the  step-by-step  process  of  attaining  the 
qualitative  and  quantitative  objectives  of 
the  program; 

.  detail  the  current  and  projected  division  of 
labor  between  responsible  organizations  in  a 
manner  consistent  with  the  objectives  and  plans 
of  higher  level  authority; 

.  indicate  the  relationships  between  supporting 
objectives  and  the  end  of  work  objectives; 

.  include  only  activities  and  events  which  have 
been  defined  by  competent  authority; 

.  provide  the  structure  for  a  meaningful  reporting 
system  for  program  management  use; 

•  be  so  constructed  that  they  coordinate  or 
interface  with  programs  of  lateral,  higher, 
or  lower  level  authority; 

.  be  used  on  a  continuing  basis  as  an  effective 
communication  device  to  integrate  the  objectives 
and  activities  of  the  various  program  managers, 
their  operating  managers,  and  other  external 
organizations  concerned. 

The  statistical  data  must: 

.  be  derived  after  definition  of  the  work  to 
be  done  within  the  activities  to  be  accomplished; 

.  derive  from  an  approved  source,  which  is  either 
the  responsible  organization  having  cognizance 
over  the  work  or  the  organization  performing 
the  work. 
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CHAPTER  VIII 


SCHEDULING  TO  ACHIEVE  OBJECTIVES 


CHAPTER  VIII 


SCHEDULING  TO  ACHIEVE  OBJECTIVES 


Scheduling  may  be  defined  as  the  translation  of  a  plan 
into  a  timetable  with  specific  calendar  dates,  which  will 
govern  the  start  and  completion  of  work  and  authorize  the 
expenditure  of  resources.  The  schedule,  when  approved  by 
responsible  management: 

.  alerts  lower  level  organizations  and 

authorizes  the  use  of  resources  including 
money  and  time; 

.  permits  continuous  comparative  analysis  of 
schedule  versus  actual  accomplishment,  thereby 
enabling  measurement  and  evaluation  of  status 
and  forecast  of  progress. 

The  goal  of  the  scheduling  function  is  to  bring  into 
being  an  approved  authoritative  schedule.  Scheduling 
requires  a  high  degree  of  skill  and  knowledge  of  the  re¬ 
quirements  of  the  activities  to  be  accomplished,  and  the 
capacities  available.  It  is  the  means  by  which  the  resource 
demands  of  several  programs  or  projects  can  be  established 
and  managed.  The  balancing  of  these  multiple  and  competing 
requirements  for  resources  is  a  responsibility  of  top  local 
management.  This  chapter  emphasizes  the  importance  of  this 
function  as  a  discrete  and  integral  part  of  the  management 
process. 

Emphasis  is  placed  on  the  scheduled  start  date  as  well 
as  on  the  scheduled  completion  date  for  planned  activities. 
This  is  to: 

.  alert  and  authorize  the  responsible 
organization  to  get  ready  to  start  the 
effort; 

.  establish  the  earliest  possible  date  to 
detect  a  significant  deviation  from 
plan;  and 

.  verify  the  completion  of  activities  or 
relief  of  constraints. 
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A.  Nature  of  the  Scheduling  Function 


An  approved  plan  is  translated  into  a  schedule  by 
assigning  resources  and  facilities  to  accomplish  the  planned 
tasks  during  specific  calendar  time  periods.  A  major  con¬ 
straint  in  scheduling  is  the  requirement  to  conform  to  the 
plan.  In  the  scheduling  process  a  manager  and  scheduler 
must  consider: 

.  the  availability  of  the  required  man¬ 
power,  equipment,  and  facilities  during 
specific  calendar  time  periods; 

.  sequencing  of  the  work; 

.  consideration  of  conflicting  demands  of 

other  programs  on  the  same  skills  or  resources; 

.  adequacy  of  available  local  capacity  and  its 
augmentation  potential; 

.  funding  limitations; 

.  the  minimization  of  premium  costs  and  idle 
time  for  manpower,  equipment,  and  facili¬ 
ties; 

.  the  manager's  judgment  of  a  reasonable 

time  for  performing  the  work  under  existing 
constraints; 

.  technical  constraints  in  the  form  of  uncer¬ 
tainties  in  activities  which  may  require  the 
provision  of  extra  time; 

.  the  local  procedure  for  the  development 
and  communication  of  work  authorization; 

.  local  management  policy  with  respect  to 
work  practices  (i.e.,  single  versus  multiple 
shifts,  union  contract  provisions,  vacation 
policy,  etc. ) ; 
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.  laws  governing  work  practices; 

.  difficulties  involved  in  scheduling 
detail  far  in  advance; 

.  varying  number  of  work  days  per  month 
and  translation  to  calendar  dates. 

All  these  considerations  bear  significantly  on  the 
problem  of  scheduling.  Each  must  be  weighed  and  balanced 
against  other  offsetting  considerations. 

Methods  vary  widely  for  converting  time  estimates  for 
activities  into  specific  calendar  dates  for  starting  and 
completing  the  work.  For  example,  large  packages  of  work 
may  first  be  blocked  into  so-called  master  schedules  to  be 
used  as  a  control  in  further  scheduling.  Each  activity  in 
such  a  block  may  then  be  scheduled  until  ultimately  the 
entire  block  is  scheduled.  Conversely  each  activity  may 
first  be  scheduled  as  a  single  unit. 

Schedule  formats  will  also  vary.  However,  regardless 
of  the  method  used  for  developing  and  communicating  schedules, 
they  become  authorizations  for  performing  the  work  only  with 
management  approval  of  their  reasonableness  for  accomplishing 
the  entire  plan  within  the  directed  date.  'This  approval 
requires  a  management  appraisal  of  the  risks  involved  in  the 
various  parts  of  the  program  and  the  advisability  of  reserving 
time  and  possibly  resources  for  unanticipated  problem  areas. 

This  manual  recognizes  the  importance  of  the  scheduling 
function  to  achieve  objectives  as  separate  and  discrete  from 
the  function  of  planning  to  achieve  objectives. 

The  interdependence  between  planning  and  scheduling  must 
be  maintained  through  the  life  of  the  planned  effort.  Any 
tendency  to  disturb  the  logical  relations  between  these  two 
functions  should  be  avoided.  Principles  involved  in  this 
relationship  include: 

.  the  approved  plan  must  govern  the  sequence 
and  content  of  work  to  be  performed; 

.  the  schedule  must  validate  the  plan  by  con¬ 
verting  it  to  a  feasible  timetable  which 
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can  be  approved  by  management.  If  the 
schedule  cannot  for  any  reason  validate  the 
plan,  appropriate  changes  must  be  made  to  the 
plan; 

.  the  schedule  will  not  change  the  planned 
sequence  of  work.  It  will,  with  the 
approval  of  management,  set  the  timetable 
which  will  actually  govern  the  start  and 
completion  of  work  and  resource  expendi¬ 
tures  required  by  specific  activities  in 
the  plan; 

.  scheduling  and  planning  must  be  so  per¬ 
formed  and  continuously  related  that  there 
is  in  effect  at  any  one  time  only  one 
scheduled  plan  for  a  given  program  approved 
by  management. 

B.  Scheduled  Dates  versus  Directed  Dates 


Some  confusion  has  historically  been  generated  by  an 
indiscriminate  use  of  the  words  "scheduled  dates"  or  "directed 
dates".  When  a  higher  level  passes  objectives  on  to  a  lower 
level  for  planning  purposes,  these  objectives  are  often 
accompanied  by  a  "directed"  date.  This  is  not  to  be  confused 
with  "scheduled"  date,  although  the  two  may  coincide.  If 
the  "directed"  date  cannot  be  met,  the  scheduling  activity 
must  notify  the  planning  activity  so  that  higher  level  plan¬ 
ning  and  validation  of  the  plan  can  be  adjusted.  The  sched¬ 
uler  does  not  alter  the  plan. 

C.  Relationship  of  PERT  to  Scheduling 

An  important  function  of  scheduling  involves  validation 
of  the  plan  depicted  by  PERT  networks.  Validation  of  the  plan 
is  the  verification  of  the  availability  of  the  resources  re¬ 
quired  for  achievement  of  the  objectives  as  depicted  in  the 
network.  Given  unlimited  resources,  the  "expected  times" 
and  the  "expected  dates"  derived  in  planning  might  be  auto¬ 
matically  used  as  the  schedule.  It  is  unlikely,  however, 
that  this  situation  will  occur.  The  network  calculations 
were  made  with  time  estimates  based  on  the  conduct  of  acti¬ 
vities  with  normal  availability  of  resources.  However, 
because  of  peak  loads,  the  resources  needed  for  an  activity 


VIII-4 


will  not  always  be  available  to  it.  Hence,  the  scheduling 
process  will  generally  require  some  changes  in  the  network 
plan  in  order  to  insure  that  activities  can  be  performed 
with  the  specific  resources  available. 

Some  users  of  PERT  have,  in  error,  tended  to  take 
mechanical  and  automatic  steps  to  arrive  at  program  schedules 
by: 

.  "crashing"  all  activities  into  minimum 
possible  times  and  relying  completely  on 
slack  time  as  a  measure  of  effectiveness 
or  need  for  additional  resources; 

.  scheduling  only  completion  dates  for 
activities  and  ignoring  start  dates. 

These  steps  fail  to  consider  the  conflicting  need  for 
resources.  Scheduling  considerations  are  so  interdependent 
that  such  steps  as  a  substitute  for  judgment  must  be  avoided. 

Validation  of  the  plan  depicted  by  the  PERT  network 
should  include  the  following: 

.  analysis  of  the  network  and  associated 
expected  time  estimates; 

.  study  of  the  individual  activity  and  path 
slack  values; 

.  study  of  "earliest  expected"  and  "latest 
allowable"  dates  for  events  and  the  related 
periods  of  time  in  which  calculations  indi¬ 
cate  activities  should  start  and  complete; 

.  decisions  to  schedule  specific  activities: 

a.  according  to  the  earliest  expected  dates, 

b.  between  the  earliest  expected  and  latest 
allowable  dates,  or 

c.  earlier  or  later  than  either  of  these; 

.  validation  or  change  of  the  time  estimates 
produced  during  planning; 
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.  subsequent  study  of  any  revision  in  the 
networks  and  accompanying  data,  occasioned 
by  changes; 

.  coordination  with  other  appropriate  personnel 
organizations . 

The  three  time  estimates  provided  in  the  planning 
function  provide  the  scheduler  with  an  additional  source 
of  information.  Certain  activities  possess  an  inherent 
high  degree  of  uncertainty  in  the  amount  of  time  which  they 
will  require.  This  will  be  indicated  by  the  spread  of  the 
three  time  estimates.  Schedulers  must  take  this  uncertainty 
into  account  in  considering  possible  schedule  alternatives. 

D.  Expected  Time  versus  Scheduled  Time 

The  process  of  estimating  expected  time  must  be  clearly 
separated  from  the  process  of  scheduling.  The  scheduled 
time  (ts)  may  be  shorter,  the  same  as,  or  even  longer  than 
the  expected  time  (te)  determined  in  the  planning  process. 

In  scheduling,  an  earliest  completion  date^Se)  and 
a  latest  completion  date^Sj,)  for  each  activity  in  the  net¬ 
work  must  be  calculated  in  the  same  manner  as  the  expected 
date  and  the  latest  allowable  date.  The  only  difference  is 
that  scheduled  time  (ts)  values  for  network  activities  which 
have  been  scheduled  are  used  in  the  calculation.  Subsequent 
to  the  establishment  of  initial  schedule,  these  calculations 
should  be  made  available  to  the  schedulers  on  a  routine 
basis. 

When  a  program  is  of  long  duration  it  may  not  be  possi¬ 
ble  to  commit  resources  in  detail  to  specific  time  periods 
through  an  entire  plan.  Where  this  situation  prevails, 
expected  time  values  should  be  processed  as  scheduled  time 
values  until  scheduling  is  actually  accomplished. 


See  Glossary  of  Symbols,  Standard  Abbreviations,  and 
Terms,  Appendix  D. 
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E.  Study  of  Slack  Values  Based  on  Expected  Elapsed  Time 


The  slack  time  values  for  individual  activities  and 
paths  through  the  network  indicate  a  latitude  of  time 
within  which  the  activities  or  the  paths  should  start  or 
complete. 

The  "latitude"  or  "cushion"  may  be  used  as  a  vital 
resource.  Whenever  the  activities  being  scheduled  are 
on  a  slack  path  the  scheduler  can  use  this  slack  time 
to  even  peak  demands  on  particular  resources.  This  point 
is  stressed  even  though  slack  values  are  based  on  expected 
time  estimates.  In  refining  expected  date  to  the  scheduled 
date  for  start  or  completion  or  an  individual  activity  or 
path,  the  scheduler  must  know  the  slack  values  in  local 
areas  of  the  plan  before  taking  action  to  schedule. 

The  action  of  the  scheduler  in  distributing  the 
slack  value  inherent  in  a  given  path  in  no  way  violates 
or  changes  the  plan  itself.  Other  work  in  process  in  the 
same  organization  may  preclude  the  application  of  slack 
which  requires  a  change  in  resource  application.  Such 
situations  may  be  resolved  only  by  higher  level  management. 

F.  Validation  of  the  Schedule 


Once  the  schedule  has  been  drafted,  scheduling  must 
feed  back  the  necessary  input  data  for  revision  of  plan. 
Entries  into  appropriate  PERT  input  forms  by  the  scheduling 
organization  or  other  designated  personnel  subsequent  to 
schedule  decisions,  will  provide  the  necessary  basis  for 
changes  in  PERT  records.  However,  before  these  decisions 
are  placed  in  the  PERT  master  data  processing  file,  and 
prior  to  any  promulgation  of  the  newly  developed  schedules 
as  the  official  schedule,  a  special  "simulation"  run  of  this 
input  data,  in  conjunction  with  appropriate  data  in  the  master 
file,  should  be  made.  This  impact  of  the  newly  developed 
schedule  on  the  plan  can  be  assessed  by  both  scheduling  and 
planning  personnel  prior  to  its  official  adoption.  If  more 
than  one  cycle  of  simulation  is  required,  this  can  be  con¬ 
tinued  until  the  schedule  is  consistent  with  management  re¬ 
quirements. 
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G.  Study  of  Revised  PERT  Networks  and  Data 


At  the  time  the  schedule  for  individual  activities  and 
events  is  initially  established,  the  expected  completion 
date  may  be  the  same  as  the  scheduled  completion  date.  Once 
the  program  is  underway  and  changes  occur,  the  calculated 
earliest  completion  date  may  move  ahead  or  behind  the 
assigned  scheduled  completion  date  for  an  activity.  Since 
this  calculated  date  is  likely  to  change  frequently  as  the 
program  continues,  it  would  be  impractical  to  change  the 
schedules  every  time  there  is  a  change  in  the  earliest 
completion  date  for  an  activity.  Rather,  changes  in  this 
date  should  serve  as  one  indicator  for  a  scheduler  in  re¬ 
appraising  his  schedule  and  resource  requirements.  When 
this  date  deviates  consistently,  necessary  adjustments  in 
the  schedule  should  be  made. 

Following  scheduling  of  particular  activities  in  the 
program  and  the  introduction  into  PERT  master  files  of 
scheduled  elapsed  time  or  scheduled  completion  dates  to 
replace  expected  elapsed  time  (te)  for  these  scheduled 
activities,  slack  values  for  these  activities  and  the  paths 
containing  them  are  automatically  calculated  by  the  computer 
and  printed.  Scheduled  activity  time  values  and  expected 
activity  time  values  for  those  parts  of  the  plan  not  yet 
scheduled,  are  merged  in  slack  path  calculations.  Positive 
slack  must  be  reviewed  with  reserve  after  scheduling  of 
activities  on  segments  of  paths  has  occurred.  Accordingly, 
managers  should  use  this  as  only  one  indicator  in  accom¬ 
plishing  schedule  revisions  to  offset  negative  slack  condi¬ 
tions.  There  should  also  be  an  awareness  that  critical 
areas  of  the  program  may  be  found  in  areas  of  the  program 
having  a  positive  slack  condition.  Accordingly,  only 
experienced  personnel  should  be  used  in  translating  slack 
into  schedule  or  resource  allocation  changes. 

H.  Rescheduling 

The  need  for  updating  the  schedule  may  occur  as  a 
program  proceeds  for  the  following  general  reasons: 

.  change  in  the  prime  or  supporting  objectives; 

.  change  in  plans  to  achieve  objectives; 
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.  schedule  slippage  or  gains  affecting  the 
timing  of  related  activities  in  the  plan 
which  require  rescheduling; 

.  change  in  funding. 

The  method  for  rescheduling  is  similar  to  the  original 
scheduling  process.  Formal  procedures  for  rescheduling  should 
be  established  for  adjusting  schedule  and  communicating  these 
adjustments  to  others  involved  in  the  program.  These  formal 
procedures  should  also  permit  ready  appraisal  of  the  effect 
of  the  rescheduling  changes  by  all  personnel  concerned. 
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CHAPTER  IX 


INPUT  PREPARATION 


CHAPTER  IX 


INPUT  PREPARATION 


When  a  schedule  has  been  approved,  work  is  authorized 
and  the  program  effort  commences.  In  parallel  with,  and  as 
a  part  of,  the  PERT  TIME  System  Cycle,  the  operating  phase 
then  commences.  The  four  major  elements  of  this  phase 
(Figure  VI-1,  Chapter  VI)  are  the: 

.  preparation  of  input  data; 

.  processing  of  input  data; 

.  preparation  of  reports;  and 

.  evaluation  of  reports. 

These  elements  comprise  the  subject  of  the  next  four  chapters. 

This  chapter  describes  PERT  data  inputs  and  their  pre¬ 
paration  for  computer  processing.  The  procedures  relate  to 
processing  of  input  data  by  the  Designated  Processing  Agency 
using  the  USAF  PERT  TIME  computer  program. 

A.  Input  Data  Preparation 

The  preparation  of  data  for  processing  begins  when  the 
network  has  been  drawn,  events  have  been  coded,  and  activi¬ 
ties  labeled  with  three  time  estimates. 

AFSC  Forms  30  and  30A  are  the  only  forms  required  for 
operation  with  the  PERT  TIME  System.  The  network  shown  in 
Figure  IX-1  will  be  used  as  an  example  for  the  preparation 
of  the  data.  Figures  IX-2a  through  IX-2d  show  the  network 
data  transferred  to  AFSC  Forms  30  and  30A.  The  data  from 
these  forms  is  subsequently  transferred  to  key  punch  cards 
for  input  to  the  computer  program. 

The  following  paragraphs  contain  the  detailed  instruc¬ 
tions  for  preparation  of  AFSC  Forms  30  and  30A.  A  con¬ 
densation  of  these  instructions  is  printed  on  the  reverse 
side  of  Form  30,  as  shown  in  Figure  IX- 2b.  The  Form  30  has 
two  data  areas: 
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FIGURE  JI-2a  —  SAMPLE  INPUT  DATA  FORM 
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FICURE  H-2b  —  INSTRUCTION  SHEET  FOR  INPUT  DATA  FORM 
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FIGURE  IX-2c— SAMPLE  INPUT  DATA  FORM 
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FIGURE  H-2d  — SAMPLE  INPUT  DATA  FORM 


.  The  initial  card  information  at  the  top 
of  the  form  represents  the  job  order  or 
instructions  to  the  computer  for  a 
particular  run. 

.  The  transaction  cards  portion  of  Form  30 
which  is  continued  by  the  use  of  Form  30A 
accepts  the  network  information  for  acti¬ 
vities  and/or  events. 

.  A  one-line  entry  is  used  for  each  activity 
or  event.  When  it  is  desired  to  use  activity 
titles  and  other  special  activity  identifi¬ 
cation  to  supplement  the  information  pro¬ 
vided  by  a  single-line  entry,  two  lines  are 
used  to  record  the  complete  information  for 
each  activity. 

Initial  Card 


Following  is  a  description  of  the  data  columns  on 
the  AFSC  Form  30  used  for  initial  card  preparation.  The 
top  portion  of  Figure  IX-2a  is  filled  out  only  once  for 
a  particular  run  since  it  contains  the  instructions  for 
what  should  be  printed  out  in  that  run. 

Column  1-7:  Report  Date.  This  is  the  cutoff 

date  for  the  report,  e.g.,  0lJan63. 


8-9:  Run  Number.  This  number  provides 

a  convenient  method  of  network  con¬ 
trol  for  the  user  and  is  printed  in 
the  output  heading.  The  run  number 
must  be  01  for  each  initial  network 
run  and  must  be  greater  than  01  for 
update  runs. 

10:  Blank  -  (For  use  by  computer  pro¬ 

grammers  only) 

11:  Blank  -  Not  used. 

12:  Master  File  Report.  This  is  a  listing 

of  the  current  network. 

Blank  -  Pert  Master  File  Report  not 
requested. 

1  -  PERT  Master  File  Report  requested. 
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13-18: 


Start  Date  of  the  Network.  The 
computer  will  start  computations  from 
this  date.  It  must  be  the  earliest 
known  or  established  for  the  network 
e.g.,  013063  for  Jan.  30,  63. 

19 •  E-L  Chart  -  By  Weeks. 

Blank  -  No  E-L  Chart  requested. 

1  -  E-L  Chart  with  D — D  spread. 

2  -  E-L  Chart  with  D — D  spread  omitted. 
A  report  date  must  always  be  given  if 
an  E-L  Chart  is  desired,  since  it  is 
used  as  the  starting  point  for  the 
Chart. 

20:  Summary  Report.  This  code  indicates 

whether  a  summary  report  is  desired 
and  designates  the  level  of  the  sum¬ 
mary.  When  a  certain  level  is  desig¬ 
nated,  all  higher  levels  of  summary 
will  also  be  printed  out.  The  letters 
"A"  through  "0"  may  be  used. 

Blank  -  No  Summary  requested. 

A  -  Summary  on  level  A  requested. 

B  -  Summary  on  levels  A  and  B  requested. 
C  -  Summary  on  levels  A,  B,  and  C 
requested. 


-  etc.,  through 

0  -  Summary  on  levels.  A,  B,  C,  ... 

0  requested. 

1  -  Minimum  Summary.  A  summary  network 
containing  only  those  events  required  to 
maintain  the  logic  of  the  detailed  network. 

21:  Event  Output  Options  -  A  code  number 

(1  through  7)  is  entered  to  indicate 
the  type  of  event  output  desired. 

Blank  -  No  event  output. 


See  Glossary  of  Symbols,  Standard  Abbreviations,  and 
Terms,  Appendix  D. 
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1  -  Event  output  ordered  by  event  number. 

2  -  Event  output  ordered  by  expected  date. 
3-1  and  2. 

4  -  Event  output  ordered  by  slack. 

5- 1  and  4. 

6- 2  and  4. 

7- 1,  2,  and  4. 

22:  Blank  (not  used). 

23 :  Run  Date. 

Blank  -  Run  date  is  included  in  the  output. 
1  -  Run  date  is  omitted. 

24:  Blank  -  (not  used), 

25-30:  Network  Completion  Date,  e.g.,  013063 

for  January  30,  1963.  This  date  is 
used  for  reverse  computations,  i.e., 
to  establish  TL  for  events. 

31-36:  System  Number  (First  line,  first 

field  of  output  heading  -  6  alpha¬ 
numeric  character  field) .  This  is 
the  system  number  that  will  be  printed 
in  the  heading  of  the  selected  output 
reports. 

37-72:  Output  title  (First  line,  third  field 

of  output  heading  -  36  alpha-numeric 
character  field).  This  field  may  be 
used  as  desired.  The  entries  will 
appear  in  the  output  headings. 

73-78:  User's  Symbol  of  Identification  (Second 

line,  last  field  of  output  heading  - 
6  alpha-numeric  character  field) . 

79:  E-L  Chart  -  By  Months. 

Blank  -  No  E-L  Chart  requested. 

1  -  E-L  Chart  requested. 

80:  Activity  Output  Options.  A  code  number 

(1  through  7)  is  entered  to  designate 
the  type  of  activity  output  desired. 
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Blank  -  No  activity  output. 

1-  Activity  output  ordered  by  ending/ 
beginning  event  numbers  (EE-BE). 

2  -  Activity  output  ordered  by  activity 
expected  end  time. 

3  -  1  and  2. 

4  -  Activity  output  ordered  by  activity 
slack. 

5- 1  and  4. 

6- 2  and  4. 

7- 1,  2,  and  4. 

Transaction  Card  Input  Data  (for  first  line  of  activity 
information) 

The  following  explanation  pertains  to  the  data  portion 
of  Forms  30  and  30A  as  used  for  recording  the  first  line  of 
information  for  each  activity.  Examination  of  Figure  IX-2a 
will  show  how  this  entry  is  made. 

Column  Is  Transaction  Code.  Transaction  codes  are  used 
to  indicate  the  action  to  be  taken  in  proces¬ 
sing  each  line  entry.  The  following  codes 
are  used: 

TC-1:  Code  1  indicates  a  new  activity  to 
be  added.  All  activities  for  the 
first  run  of  a  network  will  have 
this  code  with  the  exceptions  cited 
under  TC-3. 

All  fields  of  the  "Input  Format 
for  Activity  Cards"  are  applicable. 
Scheduled  dates  may  be  included  with 
any  activity  and  will  be  automatically 
associated  with  the  ending  event  of  the 
activity.  Actual  dates  cannot  be  en¬ 
tered  with  this  code. 

TC-2:  This  code  indicates  a  change  in  any 

one  or  all  of  the  three  time  estimates 
for  an  existing  activity.  The  new  time 
estimates  replace  the  former  ones.  If 
the  time  estimates  are  left  blank,  no 
change  in  the  previous  estimates  is 


IX- 10 


made.  This  code  is  also  used 
to  change  the  interface  flags  and/or 
level  codes.  If  columns  5,  14,  15, 
or  24  are  blank,  nothing  is  done  to 
the  interface  flags  or  level  codes. 

A  zero  in  any  of  these  columns  will 
delete  the  corresponding  interface 
flag  or  level  code.  An" I"  in  columns 
5  or  15  will  add  an  interface  flag  for 
corresponding  event,  and  a  letter 
"A"  through  "0"  will  add  a  level  code 
for  the  corresponding  event.  To  change 
an  interface  flag  or  level  code,  this 
2  code  must  contain  the  same  activity 
as  was  used  initially  to  establish 
the  interface  flag  and/or  level  code. 

(This  does  not  apply  when  adding  a  new 
interface  flag  or  level  code.)  If  the 
level  code  or  interface  flag  was  assigned 
to  an  event  more  than  once,  a  2  code  must 
be  used  with  each  activity  that  contained 
the  flag  or  code.  When  using  this  trans¬ 
action  code,  column  3  must  be  blank, 
and  the  activity  must  be  defined  by 
its  two  event  numbers  in  columns  6-13 
and  16-23.  Columns  5,  14,  15,  24,  and 
25-36  are  used  as  mentioned  above.  All 
other  columns  are  not  used. 

TC-3:  A  3  code  is  used  to  add,  change,  or  delete 
a  scheduled  date,  to  add  or  change  the 
scheduled  date  over  latest  date  option, 
and/or  to  add  or  change  the  title  of  a 
particular  event.  This  might  be  con¬ 
sidered  an  event  information  code.  The 
program  will  take  the  event  number  from 
colums  16-23,  and  if  a  scheduled  date  is 
given,  store  that  date  and  the  scheduled 
date/latest  date  option  with  the  event 
number.  If  any  character  of  the  title 
field  is  not  a  blank,  the  program  takes 
the  information  from  columns  44-78  of 
this  input  card  as  a  description  of  the 
event  and  stores  this  title  for  output. 
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This  card  code  enables  one  to  give  a 
description  and  a  scheduled  date  to 
initial  events  and,  hence,  might  appear 
in  an  initial  run  along  with  the  tran¬ 
saction  code  1  cards.  To  change  only 
the  scheduled  date  over  latest  date 
option  associated  with  a  scheduled  date 
which  has  previously  been  included  in 
the  network,  the  scheduled  date  must 
again  be  inserted  into  the  network  by 
being  punched  in  columns  37-42  of  this 
card  together  with  the  desired  option 
in  column  3,  blank  to  omit  the  option; 
one  to  include  this  option  in  the  com¬ 
putation.  When  a  scheduled  date  is 
changed  with  this  card,  the  scheduled 
date  option  for  the  new  scheduled  date 
is  taken  from  column  3  of  this  card. 

To  delete  a  scheduled  date,  zeros  must 
be  placed  in  all  columns  of  the  date 
field.  Only  columns  1,  3,  16-23,  37-42, 
and  44-78  are  used  by  the  program. 

TC-4:  This  code  is  used  to  establish  an  actual 

date  of  completion  for  an  activity.  The 
date  is  assigned  to the  ending  event  of 
the  activity.  A  date  of  completion  will 
not  appear  in  the  output  for  this  ending 
event  until  all  activities  with  the  same 
ending  event  have  reported  dates  of  com¬ 
pletion.  Then,  the  latest  completion  date 
which  the  computer  received  will  be  inclu¬ 
ded  in  the  output  as  the  actual  date  of 
completion  for  the  ending  event.  Only 
columns  1,  6-13,  16-23,  37-42  are  used 
by  the  program. 

TC-5:  Code  5  is  used  to  delete  an  activity. 

The  only  information  needed  is  the 
beginning  and  ending  event  numbers. Care 
must  be  used  with  code  5  to  maintain 
the  desired  network. For  example  to  delete 
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an  event  linking  two  activities  to  a 
network,  two  activities  must  be  deleted 
and  one  added. 


to  delete  Event  2, 
one  must  delete  Acti¬ 
vities  1-2  and  2-3 
and  add  a  new  Activity 
1-3. 


Only  columns  1,  6-13,  and  16-23  are  used 
by  the  program. 

TC-6:  Code  6  is  used  to  add  an  actual  date  and 

if  desired  to  add  a  title  to  a  beginning 
event  of  the  network.  The  date  must  be 
greater  than  or  equal  to  the  start  date 
of  the  system.  If  only  the  event  title 
is  to  be  added,  a  TC-3  code  should  be 
used.  The  only  information  which  a  TC-6 
card  needs  is  the  event  number  in  column 
16-23,  the  actual  date  in  the  date  field 
(columns  37-42)  and,  if  included,  the 
title  in  columns  44-78. 

TC-7:  Code  7  is  not  used  at  this  time. 

TC-8:  Code  8  is  used  to  add  or  delete  a 

short  path  flag  of  an  activity.  The 
beginning  and  ending  event  numbers  must 
be  given  together  with  the  new  short  path 
flag  (blank  or  1).  Special  care  must  be 
exercised  in  using  the  short  path  flag. 

TC-9*  Code  9  is  only  used  when  activity  titles 
or  associated  data  are  entered  on  the 
second  line  of  activity  information. 

This  is  not  used  for  the  first  line  of 
activity  information. 


Column  2 :  Short  Path  Flag 

Blank  -  No  short  path  flag. 

1  -  Short  path  flag  is  desired.  If  this  flag 
is  used  all  terminal  activities  of  a  parallel 
effort  must  be  identified  with  a  "1"  (one)  in 
this  column.  The  short  path  flag  is  used  when 
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several  parallel  developments  are  under  way, 
and  it  is  desired  to  know  which  will  require 
the  shortest  time  to  completion.  The  computer 
program  will  calculate  this  path  for  all  para¬ 
llel  efforts  which  commence  with  the  same  begin¬ 
ning  event  and  conclude  with  the  same  ending 
event.  The  flag  will  appear  in  the  output  with 
the  terminating  event.  Application  of  the  flag 
is  demonstrated  by  using  the  following  network 
in  which  paths  1-2,  to  2-3,  to  3-4,  and  1-5  to 
5-4  represent  two  parallel  efforts  to  complete 
Event  4. 


Activities  3-4  and  5-4  must  be  flagged  with  a 
"1"  to  indicate  the  end  of  the  parallel  effort. 
The  program  does  not  allow  any  other  activities 
to  end  with  Event  4.  That  is,  parallel  efforts 
must  be  considered  separately  from  other  inter¬ 
actions.  Dummy  activities  can  always  be  intro¬ 
duced  if  there  are  other  tie-ins  with  Event  4. 
For  example: 
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If  Activity  7-4  represents  an  additional, 
but  not  parallel  effort  necessary  for  the 
completion  of  Event  4,  it  can  be  included 
in  introducing  Activity  4-6,  with  zero  time 
estimates  and  now  representing  the  additional 
effort  with  Activity  7-6  instead  of  7-4.  The 
expected  time  for  6  will  represent  the  longer 
of  the  two  expected  times  along  4-6  and  7-6 
where  the  expected  time  for  4  is  the  minimum 
of  the  two  times  along  3-4  and  5-4. 

Column  3:  Scheduled  Date  Option.  This  option  is  used 
to  designate  scheduled  dates  that  are  to  be 
used  in  backward  computations.  For  these 
selected  events,  the  computer  will  replace 
the  latest  computed  date  with  the  scheduled 
date  if  it  is  earlier  than  the  TL  and  continue 
the  computation  using  the  scheduled  date  as 
the  latest  date. 


Column  4:  Blank.  (For  use  by  computer  programmers  only) 

Column  5s  Interface  for  Beginning  Event. 

Blank  -  The  beginning  event  is  not  an  interface. 
I  -  The  beginning  event  is  an  interface. 

6-13 j  Beginning  Event  Number  (BE)  -  must  be  numeric 
and  greater  than  zero.  All  columns  must  be 
filled. 


14:  Level  Code  for  the  Beginning  Event.  A  letter 
"A"  through  "0"  (the  latter  should  be  written 
"0"  to  distinguish  it  from  zero  which  is  used 
in  the  same  column  for  deletion  purposes)  is 
used  to  identify  the  beginning  event  for  various 
management  levels  for  summary  or  shredout  purpo¬ 
ses.  The  level  code  need  be  included  only  once 
for  each  event. 

Blank  -  No  summary  level  designated. 

A  -  0  -  As  assigned. 

0  -  (number  zero)  -  delete  the  level  code. 

15:  Interface  for  Ending  Event. 

Blank  -  The  ending  event  is  not  an  interface. 

I  -  Ending  event  is  an  interface. 
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16-23:  Ending  Event  Number  (EE) .  Must  be  numeric 

and  greater  than  zero.  All  columns  must  be 
filled. 

24:  Level  Code  for  Ending  Event  (A  through  0) 

A  letter  "A"  through  " 0 "  (the  latter  should 
be  written  "0"  to  distinguish  it  from  zero 
which  is  used  in  the  same  column  for  deletion 
purposes)  is  used  to  identify  the  ending  event 
for  various  management  levels  for  summary  or 
shredout  purposes.  The  level  code  need  be 
included  only  once  for  each  event. 

Blank  -  No  summary  level  designated. 

A  -  0  -  As  assigned. 

0  (number  zero)  -  delete  the  level  code. 

25-28:  Optimistic  Time  Estimate.  In  weeks  and  tenths 
of  weeks.  (003.5  equals  a  time  of  3%  weeks). 
Four  digits  must  be  used. 

29-32:  Most  Likely  Time  Estimate.  In  weeks  and  tenths 
of  weeks.  (00  3.5  equals  a  time  of  3%  weeks). 
Four  digits  must  be  used.  When  single  time 
estimates  or  scheduled  times  are  used,  they  are 
placed  in  these  columns  only. 

33-36:  Pessimistic  Time  Estimate.  In  weeks  and  tenths 
of  weeks.  (003.5  equals  a  time  of  3^  weeks). 
Four  digits  must  be  used. 

37-42:  Date  Field.  These  columns  are  used  to  enter  a 

scheduled  date  for  an  event  or  actual  completion 
date  of  an  activity.  The  date  Jan  30,  1963, 
would  be  entered  as  013063. 

43:  Blank. (For  use  by  computer  programmers  only.) 

44-78:  Event  Title.  The  ending  event  title  may  be 
entered  in  this  field.  Alphabetic,  numeric, 
or  other  special  characters  available  can  be 
used  to  describe  an  event.  To  include  a  title 
with  a  starting  event,  a  transaction  code  3  must 
be  used. 

79-80:  Blank  (not  used). 
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Transaction  Card  Input  Data  (for  second  line  of 
activity  information) . 

The  use  of  data  columns  on  Forms  30  and  30A  for  the 
second  line  entry  which  records  additional  activity  infor¬ 
mation  (activity  title  and  special  activity  identification 
such  as  responsible  organization  or  department,  charge 
number,  priority  number,  etc.)  is  described  below.  Figure 
IX-2a  illustrates  how  this  second  line  entry  is  made  when 
using  only  one  of  the  four  available  fields  of  activity 
information.  The  data  entered  as  a  second  line  will  be 
printed  on  the  second  line  of  the  Activity  Reports.  (Figures 
XI-6  through  XI-8,  Chapter  XI). 


Column  1:  The  transaction  code  to  enter  activity 

titles  and  activity  associated  informa¬ 
tion  is  always  9. 

2-5:  Blank  (not  used). 

6-13:  Beginning  Event  Number  (BE) .  The  (BE) 

number  is  common  to  both  lines  of  data 
and  need  be  entered  only  on  the  first 
line. 


14-15:  Blank  (not  used). 

16-23:  Ending  Event  Number  (EE) .  The  (EE) 

number  is  common  to  both  lines  of  data 
and  need  be  entered  only  once. 

24:  Blank.  (Not  used) 

25-42:  Activity  Information.  The  activity 

associated  information  is  divided  into 
4  fields;  the  first  3  fields  contain 
4  columns  of  information  each  and  the  4th 
field  can  contain  6  columns  of  information. 
This  division  of  the  18  columns  is  promp¬ 
ted  by  the  AFSC  Form  30,  where  these  4 
fields  correspond  to  the  three  time 
estimates  and  the  date  fields.  These 
4  fields  are  used  at  the  discretion  of 
the  PERT  user.  Any  information  the  user 
desires  to  associate  with  a  given  activity 
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may  be  included.  The  information  entered 
in  any  or  all  of  these  4  fields  will  be 
printed  on  a  second  line  of  the  Activity 
Report.  Columns  25-42  may  also  be  used 
to  increase  the  title  length. 

43-78:  Activity  Title.  The  activity  title  may  be 

entered  in  this  field.  Alphabetic,  numeric 
or  other  special  characters  available  may  be 
used  to  describe  an  activity. 

79-80:  Blank  (not  used). 

B.  Updating 

1.  Updating  Process 

Once  the  initial  input  data  has  been  entered  into 
the  computer,  the  periodic  reporting  of  updated  data  com¬ 
mences.  The  network  in  Figure  IX-3  is  an  updated  version 
of  the  original  network  shown  in  Figure  IX- 1. 

The  update  report  requires  a  submittal  of  AFSC  Form 
30  or  30A.  Examples  of  entries  required  for  processing 
the  updated  network  are  illustrated  in  Figure  IX-4.  Up¬ 
dating  does  not  require  resubmittal  of  the  information 
for  all  the  activities  in  the  network,  but  submittal  only 
of  new  information.  The  information  reported  on  an  update 
will  include: 

.  all  activities  completed  during  the  last 
report  period; 

.  revised  time  estimates  for  activities  that 
were  not  completed  during  the  report  cycle, 
but  were  expected  to  be  completed; 

.  revised  estimates  for  activities  expected 
or  scheduled  for  completion  during  the  next 
cycle  which  will  not  be  completed; 

.  changes  in  the  network  such  as: 

.  new  activities  to  be  added; 
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FIGURE  Hr 3  —  UPDATED  NETWORK 
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FIGURE  3X-4 —  INPUT  DATA  FOR  UPDATING 


deletions  to  the  network; 


.  revisions  of  future  time 
estimates; 

.  corrections  to  previously 
reported  data. 

Figure  IX-4  shows  data  for  updating  the  initial  re¬ 
port  with  proper  entries  and  transaction  codes.  Referring 
to  the  updated  network  (Figure  IX-3)  and  the  accompanying 
AFSC  Form  30  (Figure  IX-4), note  that  Activity  34-210-27 
to  34-210-029  was  deleted  by  using  transaction  code  5  and 
two  new  Activities  34-210-027  to  34-210-030  and  34-210-030 
to  34-210-029  were  added  in  its  place.  Time  estimates  also 
were  made  for  these  new  activities.  Transaction  code  1 
was  used  to  insert  into  the  program  these  two  new  activi¬ 
ties  and  their  time  estimates.  A  scheduled  date  for  Event 
34-210-017  was  added  using  transaction  code  3.  Revised 
time  estimates  for  Activities  34-210-016  to  34-210-017 
and  34-210-026  to  34-210-028  were  entered  with  transaction 
code  2.  Transaction  code  4  was  used  to  enter  completion 
dates  for  three  activities  completed  between  the  starting 
date  of  15  Jul  1963  and  the  updating  report  date  of  22  Jul 
1963. 


A  computer  run  incorporating  the  updated  information 
is  initiated  by  instructions  on  the  initial  card  as  shown 
at  the  top  of  Figure  IX-4.  "Run  Number  02"  has  been  en¬ 
tered  in  Columns  8-9  to  indicate  in  the  resulting  print¬ 
outs  that  this  is  an  update  run. 

2.  Updating  by  Teletype,  Telephone,  or  Data 

Communications  Network  (Transceiver  System) 

Minor  changes  to  the  network  and  updating  of  input 
data  may  be  reported  by  teletype,  telephone  or  data  com¬ 
munication  network,  but  only  when  agreed  upon  by  the  DPA 
and  the  reporting  agency.  For  the  purpose  of  uniformity, 
the  following  procedure  will  apply: 

Authorized  submission  by  teletype  will  be  analyzed 
in  accordance  with  AF  Reg  205-53,  and  Encrypt  for  Trans¬ 
mission  Only  procedures  will  be  applied  to  those  which, 
though  individually  unclassified,  may  collectively  reveal 
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significant  information  related  to  sensitive  plans, 
programs,  or  operations.  Teletype  will  be  prepared  in 
the  format  shown  in  Figure  IX-5. 

The  first  line  in  the  body  of  the  teletype  will  con¬ 
tain  the  following  information. 

From:  Initiator 

To:  Office  of  DPA 

Project  Number 

Network  Title 

Report  Period 

Security  Classification 

Each  transaction  will  be  numbered  sequentially  be¬ 
ginning  with  the  number  "one"  and  will  be  shown  as  a  two 
line  entry.  The  data  entered  in  the  "Transaction  Code" 
field  through  the  "Scheduled  or  Completed  Date"  or  the 
"Activity  Title"  field  (Columns  43-78)  will  be  the  second 
line  entry  (on  transactions  other  than  "9",  card  column 
43  will  be  blank) .  Each  field  of  a  teletype  message  will 
be  separated  by  a  diagonal.  When  no  entries  are  required 
in  a  specific  field,  the  field  will  be  shown  as  "BLK". 

AFSC  Form  30  data  may  be  transmitted  by  telephone, 
when  authorized,  with  confirmation  copies  of  the  form  to 
follow.  The  copies  will  be  conspicuously  marked  "Confir¬ 
mation  Copy"  on  the  face  of  each  sheet. 

AFSC  Form  30  data  may  be  submitted  by  transceiver 
when  authorized.  Data  in  80  column  punch  card  format  may 
be  submitted  to  the  transmitting  station  in  accordance 
with  the  procedure  contained  in  Allied  Communications 
Publication  (ACP)  127,  USAF  Supplement  4  and  US  Supple¬ 
ment  2. 
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F1WRE-H-5—  TELETYPE  REPORTING 
FORMAT 


C.  Pitfalls  in  Data  Preparation 


Many  pitfalls  commonly  encountered  when  preparing 
data  for  PERT  computation  may  be  avoided  by  exercising 
proper  care  and  strict  adherence  to  procedures.  Listed 
below  are  some  of  the  pitfalls  commonly  encountered. 

.  Duplication  of  event  numbers  in  a  network 
or  on  the  reporting  AFSC  Form  30.  Use  of 
duplicate  numbers  will  generally  create  a 
loop  in  the  network. 

.  Repetition  of  an  activity  on  the  reporting 
form  will  cause  two  input  cards  to  be  key¬ 
punched  for  the  same  activity.  These  cards 
may  or  may  not  be  exact  duplicates,  i.e., 
they  could  have  the  same  identifying  numbers, 
but  have  different  time  estimates,  etc.  The 
first  card  is  accepted  by  the  computer  and 
the  others  dropped  from  further  processing 
although  reported  as  a  duplicate  activity  in 
the  error  report  printout,  when  this  occurs 
a  check  should  be  made  to  ascertain  that  the 
correct  activity  information  was  on  the  card 
processed  by  the  computer. 

.  Illogical  time  estimate;  e.g.,  pessimistic 

or  most  likely  time  estimates  shorter  than  the 
optimistic.  This  produces  an  error  message. 

The  "m"  value  will  be  used  in  the  computation. 

.  Reporting  an  activity  completed  before  its 
beginning  event  is  complete. 

.  Zero  time  estimates  not  shown  as  four  zeros 

on  the  reporting  form  and  therefore  not  punched 
onto  the  cards.  (The  card  will  be  rejected  by 
the  computer.) 
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Assignment  of  a  network  start  date,  which 
is  later  in  time  than  any  of  the  scheduled 
or  completion  dates  assigned  to  events  or 
activities. 

Activities  inserted  and  deleted  on  the  same 
report,  i.e.,  reporting  a  code  "1"  activity 
and  then  deleting  it  with  code  "5"  or  vice 
versa  on  the  same  run. 

Event  recording  that  does  not  fulfill  the 
following  conditions:  the  event  number 
be  an  eight  digit  number  greater  than  zero? 
and  all  column  spaces  be  filled. 

Failure  to  keep  the  number  of  transcriptions 
of  the  input  data  to  an  absolute  minimum. 
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CHAPTER  X 


DATA  PROCESSING  REQUIREMENTS  AND  LOGIC 


USAF  PERT  was  designed  for  uniform  application  of 
PERT  within  the  Air  Force.  It  considers  the  many  require¬ 
ments  of  both  Air  Force  and  industry,  and  every  effort  was 
made  to  fulfill  these  requirements. 

A.  Data  Processing  Requirements 

The  features  and  parameters  described  below  are 
requirements  of  the  system. 

.  The  system  must  have  the  capability  for  pro¬ 
cessing  networks  of  a  size  required  to  meet 
the  needs  of  management. 

.  Activity  and/or  event  titles  are  accepted  and 
printed  out. 

.  A  master  file  is  maintained  for  successive 
update  runs. 

.  When  all  activities  leading  into  a  common  event 
have  been  given  actual  dates,  the  latest  of  these 
is  taken  as  the  actual  date  for  that  event. 

.  Activities  are  not  assumed  to  have  been  completed 
until  so  reported. 

.  No  activity  can  be  reported  completed  until  all 
prior  events  have  been  reported  as  having  occurred 
and  prior  activities  have  been  reported  as  completed. 

.  Duplicate  activities  are  dropped  during  validation. 

.  All  network  start  events  may  have  a  scheduled  date 
entered.  This  scheduled  date  is  used  as  the  expec¬ 
ted  date  for  forward  computation.  If  a  scheduled 
date  is  not  given  to  a  network  start  event,  then 
the  network  base  date  is  used  as  the  expected  date 
for  the  start  event. 
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There  are  three  options  for  the  assignment  of 
latest  allowable  dates  (T^)  to  events  which  have 
no  succeeding  activities: 

.  The  scheduled  date  for  each  is 
selected  as  its  latest  allowable 
date  or, 

.  A  program  completion  date  may  be 
assigned  as  the  latest  allowable 
date  for  all  end  events  or, 

•  If  one  of  the  two  above  is  not 
selected,  the  latest  expected  date 
(Tjj)  in  the  network  is  assigned  as 
the  latest  allowable  date  (T^) . 

The  process  must  have  the  option  of  selecting  certain 
scheduled  dates  (as  designated  by  the  user)  for 
backward  computation.  These  scheduled  dates  may  be 
assigned  anywhere  in  the  network. 

The  calendar  routine  is  based  on  a  five  day  work  week 
with  holidays  considered.  The  holidays  are  controlled 
by  a  table  of  desired  holidays. 

Loops  must  be  identified  and  eliminated  from  the 
network. 

Input  is  always  by  activities. 

Networks  may  have  multiple  start  and/or  end  events. 

Three  time  estimates  for  each  activity  are  accepted. 

The  process  will  also  accept  single  time  estimates. 

Events  without  predecessors  should  be  given  actual 
dates. 

The  process  must  compute  the  probability  of  meeting 
scheduled  dates. 

Input  data  must  be  validated. 
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•  Event,  activity,  master  file  and  graphical 
reports  must  be  available  at  the  user's  option 

and  can  be  ordered  by  slack,  event/activity  number, 
or  expected  dates  as  desired.  Shredouts  of  any 
of  these  reports  may  be  selected. 

.  The  process  identifies  the  shortest  path  in 
parallel  efforts  when  the  short  path  option  is 
used. 

.  The  process  must  produce  a  listing  of  paths  in 
order  of  criticality. 

.  The  process  must  compute  the  probability  of 
positive  slack  for  each  event. 

.  An  event  standard  deviation  must  be  calculated. 

•  A  level  code  for  events  is  included. 

.  The  process  must  possess  a  network  summarization 
and  integration  capability;  and 

•  The  process  must  be  capable  of  accepting  an 
unlimited  number  of  changes  to  the  master  file. 

B.  Data  Processing  Locric 

Often  the  operators  and  users  of  the  PERT  System  are 
unaware  of  how  the  computer  processes  the  input  data  to 
produce  the  output  reports.  To  help  fill  this  gap  in  some 
PERT  operators'  knowledge  of  their  system  and  to  improve 
their  ability  to  communicate  with  the  data  processing  per¬ 
sonnel,  the  process  or  logic  used  in  the  USAF  PERT  TIME 
System  is  described  below. 

Standard  sort  routines,  file  maintenance  routines, 
input  and  output  routines  and  monitor  routines  are  utilized 
by  the  program.  The  program  is  broken  into  several  indepen¬ 
dent  sections.  Each  section  can  be  assembled  alone  and 
then  inserted  into  the  total  program,  or  all  sections  can  be 
assembled  as  one  unit. 

The  employment  of  the  standard  control  routines  and 
sectioning  of  the  program  allow  for  easy  maintenance.  It 
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also  simplifies  the  making  of  additions  and/or  changes  to 
the  program. 

The  logic  diagrams  below  show  an  overall  flow  of  the 
data  from  input  to  output.  Although  the  logic  diagram  is 
one  continuous  flow  process,  for  ease  of  reading  it  has  been 
chronologically  segmented  so  that  the  text  and  that  portion 
of  the  diagram  it  pertains  to,  appear  on  the  same  page. 

However,  before  continuing,  the  reader  should  acquaint 
himself  with  the  following  terminology  so  as  to  understand 
more  fully  the  explanation  of  the  computer  logic  presented. 
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COMPUTER  LOGIC  DIAGRAM  TERMINOLOGY 


Intermediate 


tapes. 


Option  . 


This  indicates  the  system  output  tape  for 
printing  the  reports.  The  reports  are 
stacked  on  this  tape. 


This  indicates  the  system  output  tape  from 
which  card  type  outputs  are  derived. 

ACT  TILE  -  A  file  that  contains  the  pseudo  event  nos. 

that  identify  the  activity,  te,crte,  ta,  and 
certain  program  control  data. 


BEL  File 


A  file  that  contains  the  TL,crT  ,  and  certain 
program  control  flags.  L 


Event  Nomen 

File  -  A  file  that  contains  the  event  titles. 


FEL  File 


A  file  that  contains  the 
program  control  flags. 


lE  • 


and  certain 


PEN  File  -  A  file  that  contains  the  event  numbers  in  packed 
form  and  the  level  codes. 


Rank  Backward 

File  -  The  same  as  the  rank  forward  file  except  that 

it  is  in  descending  rank  order. 


Rank  Forward 

File  -  The  same  as  the  ACT  FILE  except  that  rank  has 

been  added  and  the  file  is  in  ascending  rank 
order. 


SDL  File  -  A  file  that  is  composed  of  the  schedule  dates, 

predecessor,  successor,  and  activity  actual  date 
tallies,  and  certain  other  program  control  flags. 
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Summary 

Date  File  -  A  file  that  contains  the  summary  events  and 
their  a,  m,  and  b. 
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THE  DATA  PROCESSING  LOGIC 


Section  1.  The  transaction  cards  are  Ending  Event-Beginning 
Event-Transaction  Code  sorted  by  (EE) - (BE) -  (TC)  for  merging 
into  the  old  master  file  to  create  a  new  master  file.  If  the 
run  number  was  01,  (file  establishment),  a  fake  old  master 
file  is  generated. 

Section  2.  A  new  master  file  is  created  by  adding  the  change 
cards  to  the  old  master  file.  Simultaneously,  a  tape  of  event 
numbers  is  generated  to  be  used  by  the  pseudo  event  number 
generator  and, if  requested,  a  master  file  report.  Update 
changes  which  cannot  be  processed  by  this  phase  are  written 
in  a  separate  tape  to  be  processed  by  Phase  2.  At  the  start 
of  this  phase,  the  system  number  and  heading  on  the  initial 
card  are  checked  against  the  old  master  initial  card  to  in- 
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Section  3.  The  error  tape  generated  in  Section  2  is  read 
in  and  an  error  report  is  generated  on  the  output  tape. 
This  report  prints  out  one  of  the  following  8  messages 
with  each  rejected  update  card: 


Beginning  Event  (BE)  Incorrect.  Ending  Event 
(EE)  Incorrect  (an  alpha  character  will  cause 
either  of  these).  Level  Code  (LC)  Incorrect 
(anything  other  than  a  letter  A  through  0 
will  cause  this  message) .  Times  Bad  (an  alpha 
punched  in  a  time  field  or  an  illegal  date 
will  cause  this  message) .  Unmatched  (any 
update  card  without  an  original  in  the  old 
master  file) .  Insert  Equal  (a  new  activity 
identical  to  one  already  in  the  file) ,  Non¬ 
select  (an  illegal  Transaction  Code  TC)  and 
Seq  Error  (caused  by  not  having  blanks  in  the 
BE  field  for  a  TC  of  3  or  6) . 


Section  4.  The  input  routine  reads  the  records  from  the 
new  master  file,  assigns  pseudo  event  numbers,  creates  an 
SDL  file,  and  creates  an  activity  file  with  summary  control 
date  if  requested.  The  PEN  file  words  consists  of  eight  (8) 
digit  numbers.  The  position  on  the  list  of  an  event  number 
determines  the  pseudo  event  number.  The  level  code,  if 
given,  will  be  converted  to  a  number  0  through  15  and  stored 
in  the  right  4  bits  of  the  word. 

The  SDL  file  consists  of  an  event  nomenclature  indica¬ 
tor,  a  successor  tally,  and  actual  date  tally  and  a  pre¬ 
decessor  tally  for  each  event;  also,  when  given,  an  actual 
or  scheduled  time  for  the  event. 


The  ACT  file  consists  of  two  words  for  each  activity 
and  contains  the  two  pseudo  event  numbers,  te/ta.  ^te*  Short 
Path  (SP) ,  and  summary  control  and  actual  data  flags. 
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During  this  process  the  following  errors  are  checked 
for  and  indicated:  (1)  level  code  change,  (2)  times  wrong: 
(a  >  m  >  b) ,  (3)  transaction  code  wrong,  (4)  too  many  pred¬ 
ecessors  and  successors,  (5)  start  date  wrong,  (6)  given 
dates  wrong,  (7)  number  of  events  or  activities  exceed 
limit. 


Section  5.  A  rank  is  canputed  for  each  event  and  each 
activity  is  assigned  a  rank  based  on  its  beginning  event 
number.  The  above  list  is  ordered  by  rank  and  pseudo  be¬ 
ginning  event  number.  During  this  process  the  network  is 
checked  for  loops. 
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Section  6.  The  summarization  process  takes  a  detailed  net¬ 
work  and,  based  on  preselected  events,  constructs  a  summa¬ 
rized  version  of  that  network.  Included  in  the  summarized 
network  are  those  preselected  events,  plus  events  that  are 
included  by  the  program  to  insure  network  consistency. 
Generally,  the  program  will  have  to  include  "time  now"  type 
events,  and  all  start,  interface,  and  end  events.  An  activ¬ 
ity  reported  complete  before  its  beginning  event  is  completed 
will  be  detected  here  and  will  kill  the  run. 

Section  7.  The  summary  output  converts  the  summary  data  from 
the  previous  process  and  inserts  the  scheduled  dates  and  event 
nomenclature. 
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Section  8.  The  forward  process  computes  TE  and  cTe  and 
determines  the  Critical  Predecessor  (CP)  for  each  event. 
These  are  computed  or  created  by  passing  once  through  the 
forward  ordered  activity  list.  An  activity  reported  com¬ 
plete  before  its  beginning  event  is  complete,  if  not  de¬ 
tected  during  summarization,  or  an  accumulation  of  too  much 
time  for  Tg  will  be  detected  and  indicated. 


Section  9.  The  backward  process  computes  Tj,  and  0-Tl  for 
each  event.  These  are  computed  by  passing  once  through  the 
backward  ordered  activity  list. 
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Section  10.  The  event  assembly  gathers  all  of  the  informa¬ 
tion  concerning  each  event,  computes  the  event's  slack  and 
records  them  as  a  record  in  the  event  assembly  file.  The 
first  record  in  the  file  will  be  the  header  and  control  in¬ 
formation.  Then,  there  will  be  from  one  to  three  records 
for  each  event,  depending  on  how  many  different  orderings 
of  the  event  output  are  requested.  The  one,  two  or  three 
records  will  be  identical  except  for  the  first  two  words 
of  each  record  which  will  contain  information  pertaining 
to  the  particular  order  that  was  requested. 


Section  11.  The  event  assembly  information  is  sorted  in¬ 
ternally  or  externally,  depending  on  capacity  and  number 
of  events. 
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Section  12.  The  sorted  event  assembly  file  is  edited  for  out¬ 
put  as  follows.  The  times,  slack,  etc.,  are  converted  to  a  dec¬ 
imal,  the  times  are  converted  to  a  date,  the  probabilities  are 
computed,  and  the  event  numbers  are  unpacked.  The  above  infor¬ 
mation  is  arranged  for  printing  and  sent  to  the  output  file. 

Section  13-15.  These  sections  follow  the  same  procedure  for 
activities  that  sections  10-12  follow  for  events. 
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CHAPTER  XI 


OUTPUT  REPORTS 


This  chapter  describes  the  PERT  TIME  reports  that  are 
available  as  system  outputs.  The  reports  required  on  a 
periodic  basis  may  be  selected  from  those  displayed  in  this 
manual.  The  manager  need  not  request  all  the  reports  that 
are  discussed.  He  will  specify  which  are  to  be  generated 
for  his  program. 

The  basic  information  generated  in  the  PERT  TIME  System 
can  be  summarized  in  several  ways  for  program  management  re¬ 
porting.  The  format  and  detail  in  which  this  information 
is  presented  will  vary,  depending  upon  the  planning  and  con¬ 
trol  requirements  of  different  levels  of  management. 

The  output  reports ,  with  explanation  of  their  formats 
are  presented  in  three  groupings  as  listed  below. 

A.  Basic  Program  Management  Reports 

.  Event  Report 
.  Activity  Report 
.  E-L  Chart 

.  Summary  Network  Report 

B.  Validation  and  File  Maintenance  Reports 

.  Master  File  Report  Summary  Sheet 
.  Master  File  Report 
.  Error  Messages  Report 
.  PERT  Diagnostics  Report 

C.  Special  Purpose  Management  Reports 


Top  Management  Reports 
Other  Reports 
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A.  Basic  Program  Management  Reports 

The  basic  program  management  reports  are  the  primary 
outputs  of  the  USAF  PERT  TIME  Computer  Program.  They  pre¬ 
sent  the  PERT  data  in  various  formats  for  management's  use 
in  evaluating  the  status  of  completed  work  and  in  fore¬ 
casting  potential  problems. 
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PERT  TIME  Event  Report 


The  Event  Report  presents  the  standard  PERT  TIME  data 
for  each  event  in  the  network  (Figures  XI-1  through  XI-4) . 

The  first  three  lines  are  used  for  report  header  information. 
The  column  headings  below  identify  the  data  to  be  presented 
for  each  event. 

This  report  is  presently  sorted  in  three  orders: 

.  Sort  number  one  is  listed  in  event  number  sequence 
for  a  catalog  listing  of  events  (Figure  XI-2) ; 

.  Sort  two  is  by  expected  date,  thereby  providing  a 
chronological  listing  of  events  (Figure  XI-3) ; 

.  Sort  three  is  by  slack  from  the  least  algebraic  value 
(Figure  XI-4) . 

Figures  XI-2  through  XI-4  illustrate  printouts  of  the 
three  different  sorts  of  the  Event  Report.  Arrowheads,  which 
do  not  appear  in  the  computer  printouts,  have  been  added  in 
the  figures  in  order  to  highlight  the  column  on  which  the 
sort  for  that  report  was  made. 

Figure  XI-1  presents  the  Event  Report  format  with  an¬ 
notated  data  headings. 
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FIGURE  H-l  —  EVENT  REPORT  FORMAT 


DEFINITIONS 


PERT  TIME  Event  Report 


1 .  System  Number 

The  control  number  assigned  to  the  program  to  which 
PERT  is  being  applied. 

2 .  Name  of  Output 

Event  Report,  Activity  Report,  or  E-L  Chart. 

3 •  Output  Heading 

A  field  that  may  be  used  as  desired. 

4.  Run  Number 

A  number  that  provides  a  convenient  method  of  network 
control  for  the  user  and  is  printed  in  the  output  head¬ 
ing.  The  run  number  must  be  01  for  each  initial  network 
run  and  must  be  greater  than  01  for  update  runs. 

5.  Page  Number 
(self-explanatory) 

6.  Order  of  Output 

The  identification  of  the  means  of  sorting  the  data, 
i.e.,  event  number,  expected  date  or  slack  which  are 
printed  out  EVENT,  EDATE  or  SLACK. 

7.  Start  Date 


The  date  from  which  the  computer  will  start  computations. 
It  is  the  earliest  known  or  established  date  for  the  net¬ 
work,  e.g.,  15JUL63. 
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Computer  Program 


The  computer  program  being  used. 

9.  _  Events 

The  number  of  events  in  the  network. 

10 .  User's  Identification 

Provision  for  the  user’s  identification. 

11 .  End  Date 

The  network  completion  date,  e.g.,  02SEP64. 

12 .  Run  Date 

The  actual  processing  date. 

13.  _  Activities 

The  number  of  activities  in  the  network. 

14.  Report  Date 

The  cutoff  date  for  the  report,  e.g.,  15JUL63. 

15.  Event  Title 
(self-explanatory) 

16.  Event  Number 
(self-explanatory) 

17.  LC 

The  level  code  of  the  event. 

18.  Critical  Predecessor 

The  critical  predecessor  event. 
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19. 


LC 

The  level  code  of  the  critical  predecessor  event. 

20.  SP 

The  short  path  flag. 

21 .  Actual  Date 

The  actual  completion  date  for  the  event. 

22 .  Expected  Date 

The  expected  date  (Tg)  for  the  event. 

23.  Latest  Date 

The  latest  date  (Tl)  for  the  event. 

24.  Scheduled  Date 

The  scheduled  date  for  the  event. 

25.  Slack  Time 

The  event  slack  given  in  weeks. 

26.  Std  Dev 

The  event  standard  deviation  in  weeks. 

27 .  Prob  Scd 

The  probability  of  meeting  the  scheduled  date. 

28.  Prob  Pos  SI 

The  probability  of  having  positive  slack. 
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FIGURE  H-2— EVENT  REPORT- EVENT  NUMBER  SEQUENCE 
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FIGURE  H-3— EVENT  REPORT  -  EXPECTED  DATE  SEQUENCE 
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FIGURE  B-4—  EVENT  REPORT -SLACK  SEQUENCE 


PERT  TIME  Activity  Report 


The  Activity  Report  presents  the  standard  PERT  TIME 
data  for  each  activity  in  the  network  (Figures  XI-5  through 
XI -8) .  As  in  the  Event  Report,  the  first  three  lines  are 
used  for  report  header  information  and  the  column  headings 
below  identify  the  data  to  be  presented  for  each  activity. 

This  report,  also,  is  presently  sorted  in  three  orders 

.  Sort  one  is  by  ending  event-beginning  event  number 
(EE-BE) ,  i.e.,  where  more  than  one  activity  has  the 
same  ending  event,  they  are  further  sorted  by  beginn 
ing  event  number; 

.  Sort  two  is  by  the  expected  time  (date)  of  completion 
of  the  activity; 

.  Sort  three  is  by  activity  slack  from  the  least  alger 
braic  value. 

Figure  XI-5  presents  the  Activity  Report  format  with 
annotated  data  headings.  Examples  of  the  three  sorts  are 
shown  in  Figures  XI-6  through  XI-8. 
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DEFINITIONS 


PERT  TIME  Activity  Report 


1.  System  Number 

The  control  number  assigned  to  the  program  to  which 
PERT  is  being  applied. 

2 .  Name  of  Output 

Event  Report,  Activity  Report  or  E-L  Chart. 

3 .  Output  Heading 

A  field  that  may  be  used  as  desired. 

4.  Run  Number 

A  number  that  provides  a  convenient  method  of  network 
control  for  the  user  and  is  printed  in  the  output  head¬ 
ing.  The  run  number  must  be  01  for  each  initial  network 
run  and  must  be  greater  than  01  for  update  runs. 

5 .  Page  Number 
(self-explanatory) 

6.  Order  of  Output 

The  identification  of  the  means  of  sorting  the  data, 
i.e.,  ending  event-beginning  event,  expected  activity 
completion  time  or  activity  slack  which  are  printed  out 
EE-BE,  E  TIME  or  A  SLK. 

7 .  Start  Date 


The  date  from  which  the  computer  will  start  computations 
It  is  the  earliest  known  or  established  date  for  the  net 
work,  e.g.,  15JUL63. 
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8.  Computer  Program 

The  computer  program  being  used. 

9.  _  Events 

The  number  of  events  in  the  network. 

10 .  User's  Identification 

Provisions  for  the  user's  identification. 

11 .  End  Date 

The  network  completion  date,  e.g.,  02SEP64. 

12 .  Run  Date 

The  actual  processing  date. 

13.  _  Activities 

The  number  of  activities  in  the  network. 

14.  Report  Date 

The  cutoff  date  for  the  report,  e.g.,  15JUL63. 

15.  Beginning  Event 

The  number  of  the  beginning  event  of  the  activity. 

16.  LC 

The  level  code  of  the  beginning  event. 

17.  Ending  Event 

The  ending  event  of  the  activity. 

18.  LC 

The  level  code  of  the  ending  event. 
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19. 


Expected  End  Time 


The  activity  expected  end 
date.  If  an  "A"  precedes 
are  activity  actual  times 

20 .  Expected  End  Date 

The  activity  expected  end 


time  in  weeks  from  the  start 
this  time,  the  time  and  date 
and  dates. 


time  converted  to  a  date. 


21 .  Latest  End  Time 


The  activity  latest  end  time  in  weeks  from  the  start 
date.  If  an  "A"  precedes  this  time,  the  time  and  date 
are  actual  times  and  dates  for  the  ending  event. 

22.  Latest  End  Date 


The  activity  latest  end  time  converted  to  a  date. 

23 .  Act  Time 


The  activity  expected  elapsed  time  (a+4m+b) . 

6 


24.  Act  Siq 

The  activity  standard  deviation  (b-a)/6. 

25 .  Act  Slack 

The  latest  time  (Tl)  of  the  activity's  ending  event 
minus  the  activity  expected  end  time. 

26.  Schedule  Time 

The  event  scheduled  time  in  weeks  from  the  base  date. 
If  an  asterisk  precedes  this  time,  the  schedule  date 
option  was  exercised  for  this  ending  event. 

27.  Scheduled  Date 


The  activity  scheduled  time  converted  to  a  date. 
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28. 


Critical  Predecessor 


The  critical  predecessor  of  the  ending  event.  This  may 
or  may  not  be  the  beginning  event. 

29.  SP 

The  short  path  flag. 

30.  Event  Slack 

The  slack  of  the  ending  event. 

31 .  End  Event  Exp  Date 

The  expected  date  of  the  ending  event.  This  will  be 
equal  to  or  later  than  the  activity  expected  end  date. 
An  "A"  preceding  this  date  indicates  an  actual  date. 


XI-16 


XI-1'7 


FIGURE  E-6  — ACTIVITY  REPORT- EE -BE  SEQUENCE 
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FIGURE  E- 6  —  ACTIVITY  REPORT-  EE-BE  SEQUENCE  (cont.) 
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FIGURE  XI-7 — ACTIVITY  REPORT -EXPECTED  TIME  SEQUENCE 
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FIGURE  TT-8 — ACTIVITY  REPORT -SLACK  SEQUENCE 


PERT  TIME  E-L  Charts 


The  E-L  Chart  is  a  graphical  presentation  of  the  expect¬ 
ed  date  (E) ,  latest  date  (L) ,  scheduled  date  (S)  and  actual 
date  (A)  for  each  event  on  a  calendar  basis.  The  events  are 
sequenced  by  expected  date  and  the  heading  of  the  charts  is 
similar  to  that  on  the  Event  and  Activity  Reports. 

The  date  is  displayed  in  terms  of  weeks  from  the  report 
date  (on  an  85-week  scale)  or  months  from  the  report  date  (on 
an  85 -month  scale) .  For  the  case  where  it  is  shown  in  terms 
of  weeks  from  the  report  date,  there  is  the  option  of  display¬ 
ing  the  D — D  spread  as  three  standard  deviations  on  each  side 
of  (E)  . 

The  report  is  illustrated  in  Figures  XI-9  through  XI-11. 
Note  that  there  are  two  lines  of  print  for  each  event  except 
when  a  scheduled  date  is  given,  in  which  case  three  lines  are 
given. 
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FIGURE  2-9—  E-L  CHART  FORMAT 


DEFINITIONS 


PERT  TIME  E-L  Charts 


1.  System  Number 

The  control  number  assigned  to  the  program  to  which 
PERT  is  being  applied. 

2 .  Name  of  Output 

Event  Report,  Activity  Report  or  E-L  Chart. 

3.  Output  Heading 

A  field  that  may  be  used  as  desired. 

4.  Run  Number 

A  number  that  provides  a  convenient  method  of  network 
control  for  the  user  and  is  printed  in  the  output  head¬ 
ing.  The  run  number  must  be  01  for  each  initial  network 
run  and  must  be  greater  than  01  for  update  runs. 

5 .  Page  Number 
(self-explanatory) 

6.  Order  of  Output 

The  identification  of  the  means  of  sorting  the  data, 
which  for  the  E-L  Chart  is  expected  date. 

7 .  Start  Date 

The  date  from  which  the  computer  will  start  computations. 
It  is  the  earliest  known  or  established  date  for  the  net¬ 
work,  e.g.,  15JUL63. 

8.  Computer  Program 

The  computer  program  being  used. 
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9. 


Events 

The  number  of  events  in  the  network. 

10 .  User's  Identification 

Provisions  for  the  user's  identification. 

11 .  End  Date 

The  network  completion  date,  e.g.,  02SEP64. 

12 .  Run  Date 

The  actual  processing  date. 

13.  _  Activities 

The  number  of  activities  in  the  network. 

14.  Report  Date 

The  cutoff  date  for  the  report,  e.g.,  15JUL63. 

15 .  Event  Number 
(self-explanatory) 

16.  Slack 

The  event  slack. 

17.  Date 

The  expected  date  (Tg)  for  the  event. 

18.  E 

An  "E” ,  corresponding  to  the  expected  date,  is  printed 
in  the  appropriate  position  under  the  calendar  scale. 
For  the  E-L  Chart  by  weeks  ”D" ' s  are  used  to  display 
the  three  sigma  points. 
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19 


Title 


The  event  title. 

20 .  Date 

The  latest  date  (Tl)  for  the  event. 

21.  L 

An  "L" ,  corresponding  to  the  latest  date,  is  printed 
in  the  appropriate  position  under  the  calendar  scale. 

22.  S 

Where  a  scheduled  date  is  given,  an  "S",  corresponding 
to  the  scheduled  date,  is  printed  in  the  appropriate 
position  under  the  calendar  scale. 
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FIGURES- 10 -E-L  CHART  (WEEKS) 
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FIGURE  H-l  I  —  E-L  CHART  (MONTHS) 


PERT  TIME  Summary  Network  Report 


The  Summary  Network  Report  presents  the  PERT  TIME  data 
for  the  summarized  network.  As  described  in  Chapter  V,  a 
summary  network  can  be  constructed  using  certain  of  the 
events  that  appeared  in  the  detailed  network  and  their  con¬ 
straint  relationships.  When  a  summary  is  requested,  the 
computer  program  produces  the  event  and  activity  data  for 
the  summary  network.  While  the  prime  use  of  this  data  is 
in  the  integration  of  networks,  the  data  can  also  be  used 
to  produce  output  reports  for  the  summarized  network. 

Exactly  the  same  reports  that  are  generated  for  the  detailed 
network  can  then  be  generated  for  the  summary  network. 
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B.  Validation  and  File  Maintenance  Reports 

The  validation  and  file  maintenance  reports  audit  and 
validate  the  input  data. 
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PERT  TIME  Master  Pile  Report  Summary  Sheet 


The  PERT  Master  File  Report  Summary  Sheet  identifies 
the  reports  and  report  options  requested  and  produced  for  the 
particular  run.  This  sheet  constitutes  a  table  of  contents 
for  the  computer  run.  Figure  XI-12  presents  the  Master  File 
Report  Summary  Sheet  format  with  annotated  data  headings. 
Figure  XI-13  illustrates  a  printout  of  the  data. 
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DEFINITIONS 


PERT  TIME  Master  File  Report  Summary  Sheet 

1 .  Name  of  Output 

PERT  Master  File  Report  Summary  Sheet. 

2 .  Page 

Page  number  of  report. 

3 .  User's  Identification 

Provision  for  the  user's  identification. 

4.  System  Number 

The  control  number  assigned  to  the  program  to  which  PERT 
is  being  applied. 

5.  Output  Heading 

A  field  that  may  be  used  as  desired. 

6.  Report  Date 

The  cutoff  date  for  the  report,  e.g.,  15JUL63. 

7 .  Start  Date 

The  date  from  which  the  computer  will  start  computations. 
It  is  the  earliest  known  or  established  date  for  the  net¬ 
work,  e.g.,  15JUL63. 

8.  Report  Options 

An  identification  of  the  reports  requested  in  this  run. 

MASTER  -  Indicates  the  selected  Master  File  Report  option. 

Blank  -  No  Master  file  report  requested. 

_1  -  Master  file  report  requested. 
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E-L  CHART  -  Indicates  the  selected  E-L  Chart  option. 

No  E-L  Chart  requested. 

An  E-L  Chart  by  weeks  with  the  "D"'s  to  show 
the  three  standard  deviation  spread  was 
requested . 

An  E-L  Chart  by  weeks  without  "D"'s  was 
requested. 

An  E-L  Chart  by  months  was  requested. 

WKS-D  MOS  or  WKS  MOS  -  E-L  Charts  have  been  requested 
under  both  options. 

EVENT  -  Indicates  the  selected  event  output  sort 

option. 

SL  -  Slack  ordered  sort  requested. 

ED  -  Expected  date  ordered  sort  requested. 

EN  -  A  sort  by  increasing  event  number  requested. 

ACTIVITY  -  Indicates  the  selected  activity  output  sort 
options . 

Activity  slack  ordered  sort  requested. 

Activity  Expected  End  Time  ordered  sort 
requested. 

Activity  ending/beginning  event  number  ordered 
sort,  i.e.,  EE-BE  requested. 

SUMMARY  -  Indicates  the  selected  summary  report  option. 

Blank  -  No  Summary  Report  requested. 

A  through  letter  0  -  A  Summary  Report  summarized  to 
the  level  of  the  letter  shown  was  requested. 


SL 

ET 

EN 


Blank  - 
WKS-D  - 

WKS 

MOS 
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PERT  TIME  Master  File  Report 


The  PERT  Master  File  Report,  as  illustrated  in  Figures 
XI-14  and  XI-15,  is  a  reproduction  of  the  current  master 
file  and  is  produced  upon  request.  The  data  contained  in 
this  report  is  compared  with  previous  reports  and  the  last 
input  listing  to  assure  the  validity  of  the  current  master 
file . 
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FIGURE  E-M — PERT  MASTER  FILE  FORMAT 
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FIGURE  E-15— PERT  MASTER  FILE  REPORT 


DEFINITIONS 


PERT  TIME  Master  File  Report 

1 .  Name  of  Output 

PERT  Master  File  Report. 

2 .  Page 

Page  number  of  report. 

3.  TC 

Transaction  Code. 

4.  SP 

Short  path  flag. 

5.  SCH  OPT 

Schedule  date  option  flag. 

6.  Beg  Event 

Beginning  event  number. 

7.  LC 

Beginning  event  level  code. 

8.  End  Event 

Ending  event  number. 

9.  LC 

Ending  event  level  code. 

10.  Opt  Time 

Optimistic  time  estimate. 
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11. 


Mean  Time 


Most  likely  time  estimate. 

12 .  Pess  Time 

Pessimistic  time  estimate. 

13.  Sch  Date 
Scheduled  date 

14.  Act  Date 
Actual 

15 .  Event  Title 
Ending  event  title. 

16.  /1/2/3/4/ 

Activity  information.  This  field  contains  the  control 
data  information  inserted  by  the  user  which  then  ap¬ 
pears  on  the  second  line  of  information  related  to 
the  activity. 

17.  Activity  Title 
(self-explanatory) 
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PERT  TIME  Error  Messages  Report 
and  PERT  Diagnostics  Report 


The  Error  Messages  Report  identifies  errors,  such  as 
duplicate  activities,  changes  to  nonexistent  activities,  etc. 
The  computer  program  also  includes  a  list  of  diagnostics  and 
comments  which  are  printed  when  applicable. 

Included  are  operation  instructions  and  errors  found 
after  the  master  file  generation  phase.  The  possible  error 
messages  are  listed  in  Table  1.  The  complete  listing  of 
PERT  diagnostics  is  presented  in  Table  2. 
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Table  1.  Error  Messages 


1.  BE  INCORRECT 

Cause  -  the  BE  has  alpha  or  blank  characters. 

Action  -  the  record  is  omitted  and  computation 

continues . 

2 .  EE  INCORRECT 

Cause  -  the  EE  has  alpha  or  blank  characters. 

Action  -  the  record  is  omitted  and  computation 

continues. 

3.  LC  INCORRECT 

Cause  -  the  LC  for  BE  or  EE  is  other  than  an  A 
through  0  or  a  blank. 

Action  -  the  IX  is  omitted  and  computation 
continues . 

4 .  TIMES  BAD 

Cause  -  an  alpha  or  blank  is  in  the  time  field. 

Action  -  the  times  are  omitted  and  computation 
continues. 

5  •  INSERT  EQUAL 

Cause  -  the  same  activity  has  been  entered  twice 
or  more. 

Action  -  the  first  entry  is  retained  and  all 
others  are  dropped. 

6.  UNMATCHED 

Cause  -  an  update  has  been  entered  for  an  activity 
or  event  that  does  not  exist  in  the  master. 

Action  -  the  update  is  omitted. 

7.  NONSELECT 

Cause  -  the  input  card  format  is  not  correct. 

Action  -  the  input  card  is  omitted  and  computation 
continues . 
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Table  2.  PERT  Diagnostics 


1.  LEVEL  CODE  CHANGE  XX-XXX-XXX1  L2 . 

Cause  -  the  level  code  indicated  has  been  changed. 

2.  0  TIME  IS  GREATER  THAN  P  TIME.  USES  M  TIME 
XX-XXX-XXX  TO  XX-XXX-XXX. 

3.  0  TIME  IS  GREATER  THAN  M  TIME.  USES  M  TIME 
XX-XXX-XXX  TO  XX-XXX-XXX. 

4.  M  TIME  IS  GREATER  THAN  P  TIME.  USES  M  TIME 
XX-XXX-XXX  TO  XX-XXX-XXX. 

5.  XX-XXX-XXX  HAS  MORE  THAN  63  PREDECESSORS. 

Action  -  the  run  is  terminated. 

6.  XX-XXX-XXX  HAS  MORE  THAN  63  SUCCESSORS. 

Action  -  successor  tally  is  63  plus  number  shown. 

7.  START  DATE  IS  NOT  CORRECT. 

Action  -  the  run  is  terminated. 

8.  SCHEDULE  OR  ACTUAL  DATE  IS  BEFORE  THE  START  DATE. 
DELETE  DATE  XX-XXX-XXX. 

Action  -  event  Tg  is  used  in  the  computation. 

9.  NOE  EXCEEDS  12000. 

Action  -  the  run  is  terminated. 

10.  NQA  EXCEEDS  12000. 

Action  -  the  run  is  terminated. 

11.  LOOP  IN  NET.  TAKE  PROBLEM  OFF  MACHINE.  LIKELY 
EVENTS  IN  LOOP  ARE  (ALL  EVENTS  IN  LOOP) . 

12.  3SR03,  3SR04 

Cause  -  the  reporting  of  an  activity  completion 
prior  to  the  completion  of  its  beginning 
event. 

Action  -  the  run  is  terminated. 


lXX-XXX-XXX  -  will  be  the  event  number  that  is  in  question 
2 Level  Code 
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13.  3SR05 - 3SR14 

Cause  •*  the  network  cannot  be  summarized  due 
to  the  density  of  selected  events. 

Action  -  the  summary  run  is  terminated. 

14.  TIME  HAS  EXCEEDED  15.7  YEARS  (FWE  OR  BKE) . 

Action  -  the  run  is  terminated. 

15.  THESE  ACTIVITIES  HAVE  ACTUAL  DATES  BUT  THE  "BE'S" 

ARE  NOT  COMPLETED  (CHECK)  XX-XXX-XXX. 

Action  -  the  date  is  accepted  but  an  indication 

will  be  given  for  the  BE's  on  all  output 
reports.  (The  word  ERROR  will  print 
in  the  slack  columns.) 
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C.  Special  Purpose  Management  Reports 


The  special  purpose  management  reports  are  generated 
from  available  PERT  data  to  satisfy  particular  management 
requirements. 
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Special  Purpose  Management  Reports 


The  reports  described  previously  are  the  basic  PERT 
TIME  reports  that  are  presently  produced  by  the  USAF  PERT 
TIME  computer  program.  From  the  same  data  that  was  used 
to  generate  these  reports  there  is  the  potential  to  gener¬ 
ate  a  great  variety  of  special  purpose  reports. 

The  USAF  program  utilizes  a  shredout  routine  which,  in 
fact,  gives  it  the  capability  to  produce  many  such  special 
purpose  reports.  In  this  routine,  data  can  be  sorted  by 
any  column  or  combination  of  columns  on  the  output  reports’ 
line  of  print. 

An  obvious  technique  for  deriving  and  preparing  other 
special  purpose  reports  is  manual  translation  of  data  from 
computer  outputs  to  the  desired  format. 

Discussion  and  examples  of  some  special  purpose  reports 
are  presented  below. 


Top  Management  Reports 

An  important  application  of  special  purpose  reports  is 
in  reporting  to  higher  levels  of  management. 

One  means  of  generating  reports  more  specifically  aimed 
at  top  management  is  a  shredout  routine.  This  routine  will 
enable  the  generation  of  reports  in  the  same  format  ?.s  the 
basic  management  reports  but  includes  only  the  set  of  events 
or  activities  that  the  manager  desires  to  see.  If,  for 
example,  the  manager  wishes  to  see  a  report  on  all  events 
with  a  scheduled  date  earlier  than  some  calendar  date,  he 
can  have  a  sort  made  on  the  scheduled  date  column  to  pick 
only  those  events  out.  Only  the  information  for  these  par¬ 
ticular  events  will  then  be  printed  out  in  the  standard  out¬ 
put  format (s) . 

Additionally,  the  use  of  manually  derived  reports  and 
displays  is  of  particular  importance  in  presentation  to  top 
management.  Such  reports  are  discussed  in  Chapter  XII. 
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Other  Special  Purpose  Reports 


The  shredout  routine  can  be  used,  of  course,  for  the 
generation  of  many  special  purpose  reports  other  than  those 
designated  for  top  management.  It  can  be  used  to  generate 
individual  reports  by  organization  for  distribution  to  the 
organizations,  it  could  be  used  to  generate  reports  on  inter¬ 
face  events  only  for  a  study  of  the  status  of  interfaces, 
and  so  forth. 
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CHAPTER  XII 


PROGRAM  ANALYSIS  AND  PRESENTATION  TO  MANAGEMENT 


CHAPTER  XII 


PROGRAM  ANALYSIS  AND  PRESENTATION  TO  MANAGEMENT 


Analysis  of  the  PERT  data  and  the  subsequent  presenta¬ 
tion  of  the  information  to  management  are  among  the  most 
important  aspects  of  PERT  System  operation.  This  chapter 
presents  approaches  and  guidelines  for  the  performance  of 
these  functions. 

A.  The  Analysis  and  Presentation  Functions 

It  is  paramount  to  the  success  of  any  program  evalua¬ 
tion  that  the  product  of  the  analysis  be  concise,  accurate, 
and  significant  for  that  level  of  management  making  use  of 
it.  Additionally,  the  PERT  output  analysis  should: 

.  provide  continual  evaluation  of  current  and 
projected  program  status; 

.  allow  the  preparation  of  program  progress  and 
problem  reports  to  management  on  a  cyclical  basis; 
and 

.  be  regularly  used  by  management  in  the  decision¬ 
making  process  and  the  taking  of  necessary  corrective 
management  action  to  secure  timely  accomplishment 
of  program  objectives. 

Objectives  and  plans  for  their  attainment  are  initially 
generated  at  the  highest  level  and  become  progressively  more 
detailed  as  they  are  communicated  downward  through  the  or¬ 
ganization  structure.  The  reverse  is  true  of  progress  re¬ 
porting  and  evaluation  which  become  progressively  less  de¬ 
tailed  as  they  are  channeled  upward  through  the  organization 
structure. 

The  analysis  and  presentation  of  facts  in  consistent 
summary  type  reports  with  explanations  of  problems  provides 
higher  levels  of  management  with  a  basis  for  program  deci¬ 
sions.  Management  confidence  in  these  summary  reports  and 
evaluations  depends  upon  the  assurance  that  the  data  have 
been  derived  on  a  realistic  basis.  This  realism  begins  in 
the  detailed  network  level  where  estimates  and  actual  mea¬ 
surements  are  based  on  relatively  small,  easily  recognized 
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work  segments.  It  culminates  with  the  ability  of  the 
analyst  to  make  effective  use  of  the  information  available 
in  the  PERT  output  reports. 

B.  Analysis  of  the  Output  Data 

The  following  analyses  are  used  in  determining  the 
possibility  of  the  program  plan  and  the  status  of  the  pro¬ 
gram. 


1.  Feasibility  of  the  Program  Plan 

The  amount  of  slack  time  is  the  first  indication  of 
the  feasibility  of  the  program  plan.  If  there  is  zero 
slack,  the  planned  effort  fits  exactly  into  the  scheduled 
time  span.  If  there  is  excessive  positive  slack,  either 
the  scheduled  dates  cover  too  much  time,  or  the  time  esti¬ 
mates  as  a  whole,  are  optimistic. 

Most  frequently,  there  is  excessive  negative  slack. 

This  may  be  the  result  of  nonconcurrency  and/or  low  risk  in 
the  planned  work  effort,  inadequate  planning,  or  overly 
pessimistic  time  estimates.  The  presence  of  negative  slack 
means  that  the  present  plan  as  depicted  by  the  network  does 
not  conform  to  the  schedule  and  that  replanning  is  necessary 
to  meet  the  final  scheduled  date.  This  warns  the  program 
manager  of  a  schedule  problem  and  the  need  for  corrective 
action.  For  example,  for  the  network  of  Figure  IX-1, 

Chapter  IX,  where  scheduled  dates  were  initially  established 
only  for  beginning  Event  34-210-001  and  ending  Event  34-210- 
029,  2.6  weeks  of  negative  slack  exists. 

when  scheduled  dates  or  latest  allowable  dates  are  not 
applied  to  the  network  end  events,  the  analyst  will  observe 
that  the  slack  value  of  the  critical  path  is  always  zero, 
and  that  there  is  no  calculating  of  the  probability  that 
the  end  event  will  be  completed  on  time.  An  evaluation  of 
the  uncertainty  in  the  network  plan  may,  however,  be  gained 
by  an  examination  of  the  standard  deviation  for  each  event 
or  from  the  D — D  spread  shown  on  the  E-L  Chart. 


XII-2 


2.  Probability  of  Meeting  the  Scheduled  Date 


The  scheduled  date  for  an  event  can  be  compared  with 
the  expected  date  of  that  event  and  its  associated  standard 
deviation^  to  compute  the  probability  of  the  scheduled  date 
being  met.  In  this  computation,  the  following  expression 
is  used: 


Z 


T 


E 


a 


T 


E 


where  Tg  equals  the  scheduled  date  of  the  event,  Tg  equals 
the  expected  date  of  the  event,  and  <rT  equals  the  standard 
deviation  of  the  expected  date.  The  probability  of  meet¬ 
ing  the  scheduled  date  is  found  by  entering  a  normal  dis¬ 
tribution  probability  table  with  this  Z  function  (see  Ap¬ 
pendix  B) . 

End  Event  34-210-029  from  the  sample  network  in  Figure 
IX- 1  is  scheduled  for  2  Sep  64.  Its  expected  date  is  22 
Sep  64.  The  slack  of  -2.6  weeks  is  the  difference  between 
Ts  and  Tg  .  The  standard  deviation  for  the  expected  date 

(T  )  is  calculated  to  be  3.8  weeks.  Thus: 

E 


Z 


=  -2.6  =  -.68 
3.8 


See  Glossary  of  Symbols,  Standard  Abbreviations,  and 
Terms,  Appendix  D,  for  definition  of  the  standard 
deviation  of  an  expected  date  (  <r_  ) . 

J  E 
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The  area  under  the  curve  from  minus  infinity  to  minus 
0.68  is  25  percent  of  the  total  area  as  can  be  seen  from 
the  table.  This  means  that  there  is  a  probability  of  0.25 
that  the  end  event  will  be  completed  on  or  before  the  sched¬ 
uled  date.  This  is  illustrated  graphically  below. 


Assuming  for  illustrative  purposes  that  the  difference 
between  Tg  and  Tg  were  +2.6  instead  of  -2.6  weeks,  the  pro¬ 
bability  would  be  0.75,  illustrated  as  follows: 
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Thus,  it  can  be  seen  that  when  Tg  is  earlier  than  TE  ,  the 
probability  of  the  scheduled  date  being  met  is  less  than 
50  percent.  When  Tg  =  TE  ,  the  probability  is  50  percent 
and  when  Tg  is  later  than  TE  ,  the  probability  is  greater 
than  50  percent. 

3 .  Conclusions  on  Reasonableness  of  the  Network 


The  -2.6  weeks  slack  indicated  for  the  end  objective 
appears  reasonable  for  a  program  just  starting  and  planned 
for  completion  in  60  weeks.  However,  a  probability  of 
0.25  of  meeting  the  scheduled  date  indicates  trouble. 

This  combination  of  -2.6  weeks  slack  and  0.25  probability 
should  be  investigated.  One  of  the  very  common  causes  of 
such  a  combination  concerns  the  time  estimates  on  activities 
leading  up  to  this  event.  Is  the  spread  between  "a"  and 
"b"  of  some  of  the  activities  obviously  too  large?  A  wide 
spread  indicates  either  an  extreme  uncertainty  or  a  guess 
rather  than  an  estimate  by  the  estimator.  Such  a  spread 
creates  a  large  standard  deviation  for  those  activities 
which,  in  turn,  will  increase  the  uncertainty  in  TE  for  all 
succeeding  events.  However,  if  the  time  estimates  for 
these  activities  truly  represent  the  uncertainty  of  the 
work  that  is  to  be  accomplished,  then  the  uncertainty  in 
Te  is,  in  fact,  large. 

Several  conditions  illustrated  in  the  sample  network 
are  worthy  of  management  attention;  for  example,  Activity 
34-210-011  to  34-210-025  requires  about  19  weeks,  and  accor¬ 
ding  to  the  network,  operating  personnel  must  be  available 
before  the  start  of  Gmund  Equipment  Installation,  Event  34- 
210-026.  This  means  operating  personnel  will  be  available 
about  30  months  before  the  Launch  Site  is  complete.  The 
reason  for  personnel  being  available  in  the  middle  of  the 
program  should  be  established;  it  is  possible  that  they 
are  to  participate  in  Activity  34-210-026  to  34-210-028. 
However,  this  should  be  clarified  with  management.  This 
example  shows  how  titles  in  the  output  reports  help  in 
program  analysis. 

A  similar  situation  exists  with  respect  to  maintenance 
personnel  who  start  training  two  weeks  after  the  actual 
program  start  date.  The  expected  elapsed  time  to  train  these 
personnel  is  9  weeks,  and  according  to  the  event  printout. 
Event  34-210-020  is  expected  to  be  completed  by  1  Oct  63; 
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yet,  the  latest  allowable  date  that  personnel  are  required 
is  24  Aug  64,  resulting  in  45.7  weeks  positive  slack.  The 
plan  as  reflected  by  the  network  apparently  contemplates 
using  these  personnel  in  one  of  the  four  contributing 
activities  to  the  start  of  Missile  Installation,  Event  34- 
210-018,  but  the  presence  of  so  much  positive  slack  implies 
that  this  area  needs  more  planning.  In  fact,  the  presence 
of  several  paths  of  large  positive  slack  is  an  indication 
that  resource  adjustments  for  the  activities  on  these  paths 
are  permissible  and  probably  desirable.  This  should  be 
done  before  arriving  at  definite  scheduled  dates  for  some 
of  these  events,  especially  those  that  involve  the  timing 
of  training  maintenance  personnel.  Moreover,  the  presence 
of  these  large  positive  slack  paths  is  a  further  indication 
that  some  of  the  activities  in  these  paths  may  be  primarily 
"waiting",  rather  than  requiring  resources.  The  nature  of 
these  activities  that  are  essentially  "waiting"  periods 
should  be  closely  examined  to  determine  whether  or  not  they 
are  actually  consuming  resources  or  are  merely  constraints. 

The  overall  appraisal  of  the  sample  network  is  that 
it  is  reasonable;  however,  some  time  estimates  require 
validation  or  possible  revision. 

4.  Analysis  of  the  Critical  Path(s) 

The  critical  path  is  located  by  observing  those  events 
with  the  least  algebraic  slack  value.  In  the  sample  network 
the  critical  path  is  defined  by  the  series  of  events  having 
-2.6  weeks  slack.  This  critical  path  has  been  identified  in 
the  network  shown  in  Figure  XII-1.  In  addition  to  indica¬ 
ting  the  most  critical  path,  the  second  and  third  critical 
paths  are  shown. 

When  the  three  most  critical  paths  are  plotted  on  the 
network,  it  can  be  seen  that  two  common  activities  are 
associated  with  these  paths;  Activity  34-210-026  to  34- 
210-028  and  Activity  34-219-028  to  34-210-029.  If  the 
negative  slack  could  be  reduced  to  zero  on  these  three 
paths,  then  the  critical  path  for  the  program  would  fit 
the  scheduled  dates.  Note  that  Activity  34-210-028  to 
34-210-029  cannot  be  reduced  to  gain  sufficient  time  to 
help  even  if  the  activity  were  completely  by-passed. 

Looking  at  Activity  34-210-026  to  34-210-028,  and  noting 
the  three  time  estimates  (18-26-40),  it  can  be  seen  that 
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FIGURE  IE-1—  NETWORK  SHOWING  CRITICAL  PATHS 


high  uncertainty  is  associated  with  this  activity.  If 
means  were  found  to  reduce  the  time  for  Activity  34-210- 
026  to  34-210-028,  it  is  possible  that  the  entire  program 
could  be  improved  by  special  effort  in  only  one  area. 

There  should  be  a  reexamination  of  the  time  estimates  to 
obtain  more  precision  or  at  least  a  justification  of  the 
pessimistic  estimate  of  40  weeks  which  is  more  than  twice 
the  optimistic  estimate  of  18  weeks.  Figure  IX-4, Chapter 
IX,  illustrates  the  entry  of  new  time  estimates  for  activity 
34-210-026  to  34-210-028,  which  resulted  from  a  replanning 
of  that  activity  work  content. 

In  analyzing  the  critical  path,  it  must  be  realized 
that  though  the  path  shows  the  longest  time  through  the 
network,  it  does  not  disclose  technical  criticality. 
Nevertheless,  the  analyst  or  manager  should  determine  these 
technically  critical  areas  and,  if  they  are  on  the  critical 
path,  give  them  special  attention.  Generally,  the  techni¬ 
cally  critical  activities  are  characterized  by  a  wide  dis¬ 
persion  in  the  three  time  estimates. 

5.  Slack  Trend 

Analysis  of  slack  in  paths  other  than  the  most  criti¬ 
cal  path  is  also  important  to  insure  efficient  program 
execution.  Premium  effort  should  not  normally  be  used  in 
an  area  where  significant  positive  slack  is  indicated.  If 
positive  slack  is  excessive,  the  possibility  of  reducing 
the  level  of  effort  in  that  area  and  using  resources  in 
alternative  areas  of  effort  should  be  considered. 

Slack  trend,  particularly  on  critical  activities  or 
events,  should  be  closely  watched.  Rapidly  decreasing 
slack  or  increasing  slack  should  alert  management  to  the 
need  for  analysis  of  causes. 

6.  E-L  Chart  Analysis 

The  E-L  Chart  (Figures  XI-10  and  11,  Chapter  XI)  pro¬ 
vides  management  with  a  quick  program  orientation  and  high¬ 
lights  areas  which  require  analysis. 

One  of  the  most  useful  aspects  of  the  E-L  Chart  is 
the  positioning  of  the  L  in  respect  to  the  span  or  spread 
through  which  E  can  be  expected  to  occur.  For  example. 
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where  L  is  to  the  right  of  the  full  span  of  E,  as  shown 
below,  there  is  little  concern. 


However,  if  the  L  is  to  the  left  of  E  and  outside  the 
D — D  spread,  this  event  will  likely  delay  the  program. 
An  example  of  this  is  illustrated  below: 


In  Figure  XI-10  it  can  be  seen  that  the  L  is  to  the 
left  of  E  for  the  series  of  events  having  -2.6  weeks  slack. 
Event  34-210-006  shows  the  L  practically  under  the  left  D 
and,  therefore,  almost  outside  the  spread  in  which  E  is 
expected  to  occur.  The  status  of  this  event  should  be 
carefully  watched.  Events  34-210-019,  34-210-022,  and 
34-210-026  have  essentially  the  same  pattern  of  D — E — D 
and  L  relationship  except  that  these  events  have  the  L 
within  the  spread  of  D — E — D.  They  also  need  watching. 

The  most  revealing  fact  on  the  E-L  Chart  in  this  example 
concerns  the  last  event,  34-210-029,  which  could  occur  11.4 
weeks  (3  standard  deviations)  either  side  of  the  expected 
date  of  24  Aug  64.  The  fact  that  this  end  event  already 
has  2.6  weeks  negative  slack  presents  the  possibility  that 
this  event  could  conceivably  be  14  weeks  late.  This  illus¬ 
trates  the  importance  of  using  the  standard  deviations  in 
program  analysis. 

There  is  a  68  percent  chance  that  Event  34-210-029 
will  occur  within  one  standard  deviation  (3.8  weeks)  of  the 
expected  date.  There  is  a  95  percent  chance  it  will  occur 
within  two  standard  deviations  (7.6  weeks)  of  the  expected 
date,  and  it  is  almost  certain  to  occur  in  a  range  of  22.8 
weeks  which  is  three  standard  deviations  (11.4  weeks)  either 
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side  of  the  expected  date.  This  is  illustrated  as  follows: 


I 


C.  Presentations  to  Management 

Once  the  basic  information  requirements  have  been 
identified  and  procedures  established  for  collecting  and 
analyzing  the  data,  means  for  translating  the  information 
into  forms  and  reports  suited  to  the  transfer  of  knowledge 
must  be  established.  The  best  approach  in  determining  the 
information  requirements  for  various  levels  of  management 
is  to  consider  informational  needs  of  these  levels. 

The  information  reporting  system  should  furnish  answers 
to  the  following  kinds  of  questions  for  the  specific  area 
under  consideration  and  for  the  program  as  a  whole: 

.  Is  the  actual  accomplishment  meeting  current 
schedule  commitments?  If  not,  what  is  the 
extent  and  significance  of  the  differences? 

.  What  is  the  outlook  for  meeting  future 
schedule  commitments? 

.  Is  the  outlook  improving  or  getting  worse, 
and  why? 

.  What  are  the  controlling  factors  involved? 

Generally,  managers  at  any  level  want  only  the  informa¬ 
tion  from  PERT  which  concerns  their  activities  and  respon¬ 
sibilities.  This  information  must  be  in  understandable  form 
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and  easy  to  use.  Quality  rather  than  quantity  of  the  reports 
should  be  stressed. 

Use  of  high  speed  data  processing  equipment  makes  it 
possible  to  process  a  number  of  variables  and  provide  data 
for  evaluating  status  of  large  programs  involving  several 
networks  with  several  thousand  events  and  activities.  This 
affords  comprehensive  program  information  to  management  in 
a  timely  fashion. 

Through  a  progressive  summarization  process,  it  is 
possible  to  communicate  information  required  by  successively 
higher  levels  of  management  on  a  "management-by-exception" 
basis.  Detailed  information  is  always  available  to  higher 
organizational  units  on  an  "as  required"  basis.  Reports 
should  be  accompanied  by  a  brief  narrative  analysis,  in¬ 
cluding  recommendations  and  alternative  solutions  by  sub¬ 
ordinate  managers,  when  appropriate. 

Periodically,  the  entire  PERT  reporting  system  should 
be  reviewed  to  assure  that  reporting  procedures  have  not 
become  outmoded  and  that  information  requirements  for  man¬ 
agement  are  being  satisfied.  Regrouping  of  data  from  the 
regular  reporting  process  or  the  deletion  or  addition  of 
output  reports  to  individual  organizations  may  be  necessary. 

In  summarizing  information  for  display  purposes  at 
higher  management  levels,  the  following  guidelines  should 
be  observed: 

.  graphic  displays  are  preferable  to  tabular 
numerical  values  that  require  study  and 
analysis; 

.  all  management  levels  require  timely  summaries 
on  the  overall  program  status.  Specific  levels 
need  summaries  of  specific  areas  of  the  program 
within  their  jurisdiction  as  well  as  summaries  of 
any  specific  problem.  All  levels  want  and  need  the 
required  information  in  clear,  concise  and  under¬ 
standable  form; 

•  the  information  should  be  predictive  as  well  as 
historical  and  should  be  developed  only  to  the 
level  of  detail  which  is  essential  for  appraising 
specific  levels  of  management. 
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Several  examples  of  graphical  reports  that  have  proven 
useful  for  presentation  to  management  are  shown  below.  A 
trend  report,  such  as  that  shown  in  Figure  XII-2,  provides 
a  summary  and  historical  display  of  the  schedule  outlook. 

Two  more  trend  reports  are  shown  in  Figures  XII- 3  and  XII-4. 

Figure  XII-5  illustrates  a  typical  format  for  a 
milestone  report.  Information  for  such  a  report  may  be 
obtained  from  the  various  computer  reports,  such  as  the 
E-L  Chart  displayed  in  Chapter  XI.  Part  of  the  PERT  group's 
responsibility  is  to  identify  in  the  various  networks  the 
key  events  that  may  be  required  for  milestone  reports. 

A  format  which  has  proved  effective  for  briefing 
Air  Force  management  is  illustrated  in  Figure  XIII-6.  It 
provides  a  summary  of  the  most  critical  problems  for  man¬ 
agement  review  and  action. 

A  narrative  report  which  supplements  reports  identi¬ 
fying  significant  problems  is  the  Problem  Analysis  Report. 

It  serves  as  the  basis  for  formulating  and  assessing  solu¬ 
tions  that  will  minimize  or  eliminate  the  problems.  This 
report  contains  three  basic  sections: 

.  a  summary  analysis  of  the  total  contractor/ 
agency  protion  of  the  program; 

.  an  analysis  of  the  tasks  in  which  current 
or  potential  problems  exist; 

.  a  description  of: 

.  the  nature  of  the  problem; 

.  the  reason  for  schedule  variance; 

.  the  impact  of  the  problem;  and 

.  the  corrective  action  taken  or  planned 
and  the  expected  effect. 
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A  solution  formulated  as  the  result  of  problem  analysis 
will,  in  general,  take  one  of  the  following  forms  or  some 
combination  of  them.  It  will: 

.  increase  the  resources  allocated  to  the 
program  element; 

.  trade-off  resources  from  noncritical 
elements  to  elements  where  they  may 
be  used  more  effectively  with  respect 
to  the  program  plan; 

.  revise  planned  work  sequence; 

.  change  scheduled  completion  date. 

If  a  contemplated  solution  is  complex,  the  complete 
effect  of  the  proposed  changes  may  not  be  readily  apparent. 
As  an  aid  to  the  analyst,  proposed  changes  can  be  simulated 
on  the  computer.  Simulation  is  discussed  more  fully  in  the 
following  chapter. 
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FIGURE  IE- 2— SCHEDULE  OUTLOOK  REPORT 
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FIGURE  HI-3  — EXPECTED  COMPLETION  TREND 
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*  EARLIEST  COMPLETION  DATE  A=  ACTUAL  COMPLETION  DATE 

1  SCHEDULED  COMPLETION  DATE  L  =  LATEST  COMPLETION  DATE 

*  EARLIEST  COMPLETION  DATE 
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FIGURE  IE-5  —  PERT  MILESTONE  REPORT 
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FIGURE  m-6— MANAGEMENT  REVIEW  AND 
ACTION  FORMAT 
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SIMULATION 


Despite  efforts  to  adhere  to  the  scheduled  plan, 
requirements  for  changes  in  the  plan  or  even  in  the  objec¬ 
tives  may  arise  during  the  course  of  accomplishing  the 
program.  Consequently,  the  method  by  which  management  seeks 
to  achieve  the  efficient  and  economical  accomplishment  of 
assigned  objectives  must  include  an  orderly  formal  process 
for  the  incorporation  of  program  changes.  The  requirements 
for  change  may  evolve  from  the  top  down  or  the  working  level 
up.  However,  the  point  of  origin  is  not  as  important  as  is 
the  method  of  responding  in  an  orderly  manner. 

In  general,  adjustments  in  the  scheduled  plan  should 
be  accomplished  with  minimum  recycling  in  the  management 
process.  Before  a  decision  is  made  to  incorporate  a  change  in 
the  scheduled  plan,  however,  all  possible  alternatives 
should  first  be  considered.  Inherent  in  the  PERT  method¬ 
ology  is  a  simple  means  whereby  these  alternatives  may  be 
evaluated.  This  process  is  called  simulation. 

A.  Purpose  and  Use 

Two  basic  methods  of  using  the  network  plans  for  trade¬ 
off  studies  (or  determining  optimum  plans)  are  currently  in 
use  by  government  and  industry.  They  are: 

.  evaluating  alternative  network  plans;  and 

.  optimizing  application  of  resources  on  an 
established  network  plan. 

Both  methods  make  use  of  PERT  as  a  simulation  technique. 
PERT  can  be  used  for  evaluating  the  initial  network  plans 
in  the  Program  Definition  Phase  and  in  the  source  selection 
process  where  several  alternative  plans  for  arriving  at  the 
same  end  objective  will  exist.  PERT,  likewise,  can  evaluate 
alternative  portions  of  networks:  an  activity,  a  series  of 
activities,  or  a  path  or  paths  through  an  established  net¬ 
work. 
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Simulation  in  PERT  processing  may  be  used  to  reduce 
the  overall  time  span  for  a  network  by  reducing  activity 
times  along  the  critical  path.  Repetitive  network  pro¬ 
cessing  may  be  used  to  study  the  effect  of  transferring 
resources  from  slack  path  activities  to  the  critical  path 
until  some  other  path  becomes  the  critical  path. 

Engineering  Change  Proposals  (ECP)  which  involve 
significant  development  effort  or  which  affect  interfaces 
among  several  lateral  responsibilities  should  be  simulated 
before  they  are  submitted  to  higher  level  management  for 
approval.  Proposed  changes  can  be  injected  into  existing 
networks,  and  simulation  runs  can  be  made  to  determine  the 
impact  of  the  change,  either  on  a  portion  of  the  program 
or  on  the  total  program.  This  process  satisfies  the  sched¬ 
ule  impact  requirements  for  ECP's  set  forth  in  AFSCM  375-1, 
Configuration  Management. 

Simulation  is  also  useful  during  the  early  planning 
stages  of  a  program  for  testing  alternative  methods  of 
accomplishing  activities,  using  different  techniques  or 
resources  which  affect  time.  Such  simulation  may  improve 
the  initial  Program  Plan  and  reduce  the  need  for  major 
network  reworking. 

The  ability  to  simulate  changes  quickly  and  present 
management  with  alternative  courses  of  action  is  one  of 
the  most  valuable  features  of  the  PERT  simulation  technique. 

A  graphic  illustration  of  this  process,  when  a  computer  is 
used,  is  depicted  in  Figure  XIII-1.  If  more  than  one  cycle 
of  simulation  is  needed,  the  process  is  repeated  until 
management  requirements  are  satisfied. 

Simulation  is  particularly  useful  when  unexpected 
troubles  occur  and  corrective  action  is  needed  in  a  hurry. 

The  ability  to  quickly  assess  the  probable  impact  of  proposed 
or  incorporated  changes  and  give  rapid  evaluations  of  alter¬ 
natives  to  management  makes  simulation  invaluable.  However, 
the  simulation  process  need  not  always  be  employed  to  resolve 
only  the  unsatisfactory  conditions  presented,  but  rather, 
to  show  the  impact  of  alternative  courses  of  action  upon 
the  program.  For  example,  when  obtaining  authority  to  extend 
the  predetermined  program  completion  date  established  by 
higher  authority,  the  program  manager  can  present  the  simu¬ 
lation  exercises  to  show  how  he  had  attempted  to  accomplish 
the  program  within  present  resources  and  established  comple¬ 
tion  date,  and  that  it  was  not  possible. 
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FIGURE  XHI-I  —  SIMULATION  OF  PROPOSED  PROGRAM  CHANGES 
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Discretion  should  be  used  in  making  simulation  runs 
by  a  computer.  If  only  a  few  time  estimates  are  changed, 
it  might  be  more  practical  to  recompute  manually. 

B.  Reporting 

To  obtain  a  simulation  run  on  the  computer,  AFSC  Form 
30  is  prepared  in  the  normal  manner  for  updating,  submitted 
to  the  computer,  and  the  outputs  examined  to  evaluate  the 
effects.  Since  there  is  no  significant  code  on  the  AFSC 
Form  30  to  identify  a  simulation  run,  the  computer  operator 
must  be  notified  of  each  simulation  run.  He  will  then 
insure  that  the  current  computer  master  record  is  saved 
and  the  updated  (simulated)  master  record  is  destroyed  when 
it  is  no  longer  required. 
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TYPICAL  EVENT  CODING  FOR  A  MAJOR  SYSTEM 


Chapter  III  discussed  briefly  the  graphics  for  net¬ 
working  and  the  manner  in  which  events  on  the  network  are 
identified.  This  appendix  discusses  the  subject  of  coding 
and  gives  a  typical  example  of  event  coding  for  the  elements 
comprising  a  major  aircraft  system. 

As  stated  in  Chapter  III,  the  USAF  PERT  Computer  Pro¬ 
gram  uses  eight  digits  for  event  coding.  Only  three  or 
four  digits  are  used  to  identify  the  event  itself,  the 
remaining  digits  being  used  to  further  identify  or  categorize 
the  networks  and  their  related  events  in  areas  corresponding 
to  the  product  and  budgeting  breakdown  structure. 

When  budgetary  requirements  are  to  be  considered  in 
the  coding  structure,  reference  should  be  made  to  AFSC 
Program  Management  Instruction,  PMI  1-4  and  to  Air  Force 
Manual,  AFM  170-7.  These  documents  become  the  basis  for 
aligning  the  major  MPC  budget  codes  and  their  supporting 
elements  (sub-MPC's)  with  the  major  elements  of  work  in 
the  program  breakdown  structure. 

An  example  of  the  Materiel  Program  Code  (MPC)  is  as 
follows: 


,1000  0000  Vehicle  Major  MPC 

1_100  0000  Structure  Subordinate  MPC 

1110  0000  Empennage  Management  MPC 

(Major 

Subcontractor) 

The  relationship  between  the  work  breakdown  structure 
shown  in  Figure  A-l  and  the  MPC  is  readily  apparent. 

Subordinate,  management  and  functional  MPC's  are 
developed  for  new  systems  during  the  program  definition 
phase.  The  codes  are  initially  reported  in  the  Proposed 
System  Package  Program  at  the  end  of  the  program  definition. 
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FIGURE  A-l —  WORK  BREAKDOWN  STRUCTURE 
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The  established  MPC's  must  then  remain  with  the  system 
throughout  the  acquisition  phase. 

The  pages  that  follow  represent  the  event  numbering 
system  as  developed  for  an  actual  aircraft  system.  The 
work  breakdown  structure  was  initially  developed  to  corre¬ 
late  with  the  major  MPC  budget  codes  and  their  supporting 
elements  (sub-MPC's).  This  established  the  major  elements 
of  the  system  including  air  vehicle,  spares,  AGE,  personnel 
subsystem  development,  and  technical  data  representing 
the  major  MPC  items.  The  Air  Vehicle  was  then  divided 
into  the  categories  of  Airframe,  Propulsion,  Secondary 
Power,  Mission  Control,  Offensive  System,  Defensive  System, 
Reconnaissance  and  "other,"  (the  "other"  to  identify  items 
not  readily  classified  as  a  subsystem).  Similarly,  the 
other  major  categories  were  subdivided  into  their  elements 
of  hardware  or  function  to  complete  the  identification  and 
correlation  with  sub-MPC  items.  Thus,  an  event  coding 
system  was  evolved  that  has  a  direct  relationship  with 
budget  codes  permitting  a  variety  of  byproducts  to  be 
obtained  through  mechanized  procedures. 

As  shown  below,  the  coding  scheme  uses  the  first  digit 
of  the  event  number  to  identify  a  major  area  or  item  of  a 
program  corresponding  to  the  first  level  of  breakdown.  In 
like  manner  the  second,  third,  and  fourth  digits  are  used 
for  successively  lower  levels  of  breakdown,  and  the  fifth 
digit  may  be  used  optionally  as  illustrated  with  the  re¬ 
maining  digits  used  for  the  event  number  itself. 


1 


Optional 


1  600  000 


When  PERT  COST  is  used, 

Air  Vehicle - these  numbers  must  be 

selected  from  the  budget 
Airframe - coding  structure  (FMI  1-4) 

Wing  (Element  of  the  Airframe) 

Leading  Edge  (Element  of  the  Wing) 

Further  breakdown  of  the  wing  leading  edge,  or 
Department  or  functional  identification,  or 
Part  of  the  event  number  if  required. 

Event  number 
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Coding  requirements  must  be  given  appropriate  consid¬ 
eration  during  the  early  stages  of  implementing  PERT.  This 
is  especially  true  on  large  programs  when  PERT  COST  is  used 
and  where  networks  will  be  generated  by  a  number  of  com¬ 
panies  and  government  agencies  which  must  eventually  be 
integrated.  A  well  planned  coding  system  will  greatly  fa¬ 
cilitate  the  summarization  and  integration  of  networks. 

In  addition  to  the  illustrated  event  coding  system,  there 
is  provision  in  the  USAF  PERT  System  for  further  identifica¬ 
tion  of  activity  associated  information  by  using  the  four  ac¬ 
tivity  fields  of  Forms  30  and  30A  as  explained  in  Chapter  IX. 
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EVENT  NUMBERING  SYSTEM 
FOR  A  MAJOR 
AIRCRAFT  SYSTEM 


10  000  000 
11  000  000 


11  100  000 

11  200  000 

11  300  000 
11  400  000 


AIR  VEHICLE  -  DELIVERIES 

AIRFRAME  (Those  items  not  identified  with 
a  specific  component  such  as  manufacture 
and  installation  of  electrical  harnesses, 
tubing,  etc. ) 

Environmental  (Refrigeration  & 

Pressurization) 

Crew  Station  &  Escape  (Pod  plus 
installation  of  Crew  Station  equipment) 

Mating 

Empennage  (Horizontal  Stag. , Rudder, 
Vert.  Fin) 


11  500  000 
11  600  000 
11  700  000 
11  800  000 
11  900  000 


Landing  Gear 
Wing 

Forward  Fuselage 
Center  Fuselage 
Aft  Fuselage 


12  000  000  PROPULSION 


12 

100 

000 

Engine  Build-up 

12 

200 

000 

Fuel  System 

12 

300 

000 

Spike 

12 

400 

000 

Engine  Inlet  Control 

12 

500 

000 

Starter 
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12  600  000 


Engine  (Pratt  &  Whitney) 


13  000  000 
13  100  000 
13  200  000 
13  300  000 

13  500  000 


SECONDARY  POWER 

Primary  AC  Power 

Electrical  System  (Engineering) 

Hydraulic  System  &  Pneumatic  System 
(Engineering) 

Electrical  Harnesses  (Engineering) 


14  000  000 
14  100  000 
14  200  000 
14  300  000 
14  400  000 
14  500  000 
14  600  000 
14  700  000 
14  800  000 
14  900  000 


MISSION  CONTROL 
Flight  Controls 
Air  Data  Computer 
GFAE 

H.  F.  Radio 
Antenna 

Antenna  Coupler  Group 
Analog  Digital  Converter  (Navy) 
Discrete  Message  Indicator  (Navy) 
Approach  Power  Compensator  (Navy) 


15  000  000 
15  100  000 
15  200  000 
15  300  000 


OFFENSIVE  SYSTEM 
Attack  Radar 
Terrain  Following  Radar 
Navigation  and  Attack 
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15  400  000 
15  500  000 
15  600  000 
15  700  000 
15  800  000 
15  900  000 


Optical  Sight  &  Missile  Launch  Computer 
Shrike  Fire  Power  Control  Set  (Navy) 

Low  Altitude  Radio  Altimeter 
Vertical  Display  (Navy) 

Armament 
AMCS  (Hughes) 


16  000  000 
16  100  000 
16  200  000 
16  300  000 
16  400  000 


PENETRATION  AIDS  (DEFENSIVE) 
Trackbreakers 
Countermeasures  Receiver 
Countermeasures  Dispenser 
Radar  Homing  &  Warning 


17  000  000 
17  100  000 
17  200  000 
17  300  000 
17  400  000 


RECONNAISSANCE 

Side  Looking  Radar 
IF  Line  Scanner 
Photographic  Recon 
Recon  Data 


18  000  000 
18  100  000 
18  200  000 
18  300  000 


OTHER 

Final  Operations 
Field  Operations 
ETMA 
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20  000  000  SPARES  -  CATEGORY  III  &  ON 

21  000  000  AIRFRAME  SPARES 

22  000  000  PROPULSION  SPARES 

23  000  000  SECONDARY  POWER  SPARES 

24  000  000  MISSION  CONTROI,  SPARES 

25  000  000  OFFENSIVE  SPARES 

26  000  000  DEFENSIVE  SPARES 

27  000  000  RECONNAISSANCE  SPARES 


30  000  000 


ADVANCED  BUY  -  (Production  Effort  That 
Requires  Funding  Prior  to  FY-65) 


40  000  000 

41  000  000 

42  000  000 

43  000  000 

44  000  000 

45  000  000 

46  000  000 

47  000  000 

48  000  000 

48  010  000 
48  190  000 


3rd  &  4th  digits  will  be  used  for 
identification  of  GD/E  Multiple  Usage 
AGE  End  Items. 
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49  000  000 
49  100  000 
49  200  000 
49  300  000 
49  400  000 
49  500  000 
49  600  000 
49  700  000 
49  800  000 


AGE  SPARES 

Airframe  AGE  Spares 
Propulsion  AGE  Spares 
Secondary  Power  AGE  Spares 
Mission  Control  AGE  Spares 
Offensive  AGE  Spares 
Defensive  AGE  Spares 
Reconnaissance  AGE  Spares 
Multiple  Usage  AGE  Spares 


50  000  000 

51  000  000 

52  000  000 

52  100  000 

52  200  000 

53  000  000 

54  000  000 

55  000  000 


PERSONNEL  SUBSYSTEM 

PERSONNEL  EQUIPMENT  DATA  (PED) 

HUMAN  ENGINEERING/LIFE  SUPPORT  (HE/LS) 

Dynamic  Operator  Response  Apparatus 
(DORA) 

Other 

QUALITATIVE  &  QUANTITATIVE  PERSONNEL 
REQUIREMENTS  INFORMATION  (QQPRI) 

TRAINING  EQUIPMENT  PLANNING  INFORMATION 
(TEPI) 

TRAINING  EQUIPMENT  DEVELOPMENT  (TED) 1 


In  this  example,  Training  Equipment  Development  and  the 
Personnel  Subsystem  are  grouped  under  separate  subor¬ 
dinate  MPC  Codes  to  distinguish  them  from  the  general 
Training  Area  for  closer  management  surveillance. 
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55  100  000  Maintenance  Training  Equipment 

55  200  000  Operator's  Training  Equipment 

55  300  000  Training  Film 


56  000  000 
56  100  000 
56  200  000 
56  300  000 
56  400  000 
56  500  000 
56  600  000 
56  700  000 
56  800  000 
56  900  000 


TRAINING 

Training  Plan 

Airborne  Equipment  Training  Parts 
AGE  Training  Parts 
Training  Accessories 
Training  Services  to  ATC 
Training  Services  to  TAC 
Training  Services  to  Navy 
Contractor  Cross-Training 
Training  Technical  Information 


57  000  000 


PERSONNEL  SUBSYSTEM  TEST  AND  EVALUATION1 


60  000  000  DEVELOPMENT 

61  000  000  INTEGRATION  ENGINEERING  (No  known 

network  events) 


In  this  example,  Training  Equipment  Development  and  the 
Personnel  Subsystem  are  grouped  under  separate  subor¬ 
dinate  MPC  codes  to  distinguish  them  from  the  general 
Training  Area  for  closer  management  surveillance. 
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62  000  000  SYSTEM  TESTING  -  DEVELOPMENT  (not 

identifiable  to  a  specific  subsystem) 


62  100  000 
62  200  000 
62  300  000 
62  400  000 
62  500  000 
62  600  000 
62  700  000 

62  800  000 


Wind  Tunnel 
Pre-Fit  Flight  Test 
Flight  Test 

Static  and  Fatigue  Airframe  Test 
AGE  Compatibility  Test 
Mock-up  (DEI) 

Lab  Test  (not  identifiable  to  a 
specific  subsystem) 

Other  Development  Test 


63  000  000 
63  100  000 
63  200  000 
63  300  000 
63  400  000 
63  500  000 
63  600  000 
63  700  000 


RDT&E  SPARES 

Airframe  Spares 
Propulsion  Spares 
Secondary  Power  Spares 
Mission  Control  Spares 
Offensive  Spares 
Defensive  Spares 
Reconnaissance  Spares 


70  000  000 


TECHNICAL  DATA 
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APPENDIX  B 


TABLE  OF  VALUES  OF  THE  STANDARD 
NORMAL  DISTRIBUTION  FUNCTION 


As  described  in  Chapter  XII,  the  probability  that 
an  event  with  a  given  expected  date  (Tg)  will  be  comple¬ 
ted  by  a  scheduled  date  (T^)  can  be  found  in  a  probability 
table  for  the  normal  distribution  under  the  appropriate 
value  of  the  function  Z  (Where  Z  =  Tg  -  Tg/crT  )  .  This  table 
is  shown  in  Figure  B-l.  E 
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EVENT  COORDINATION  PROCESS 


APPENDIX  C 


EVENT  COORDINATION  PROCESS 


This  appendix  outlines  the  procedures  and  operations 
which  are  required  for  the  identification  and  control  of 
events  selected  for  inclusion  in  the  integrated  networks. 

A.  Purpose 

This  process  selects,  records,  coordinates,  and  stores 
those  events  which  define  and  interrelate  the  overall  sys¬ 
tem.  Figure  C-l  illustrates  the  event  coordination  concept. 
These  events  are  selected  major  milestones  and  interfaces. 
Specific  data  for  these  events  is  collected  by  an  integrating 
agency  and  maintained  in  a  Data  File.  Events  selected  from 
this  file  make  up  the  control  Event  Log.  This  log  is  issued 
by  the  integrating  agency  to  all  participating  organizations 
and  serves  to  identify  those  events  which  must  appear  in 
each  organization's  summary  network.  Criteria  for  selecting 
these  events  are: 

Interface  Events: 

.  all  events  signalling  the  necessary  transfer 
of  responsibility,  end  items,  or  information 
from  one  part  of  the  program  effort  to  another. 

Major  Milestones: 

.  all  key  events  designated  by  the  program 
manager; 

•  events  selected  by  reporting  agencies  for 
network  analysis. 

B.  Output  Reports 

Several  different  output  reports  should  be  made  avail¬ 
able  from  the  event  coordination  process.  The  reports  are 
as  follows: 
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FIGURE  C-l  —  EVENT  COORDINATION  CONCEPT 


.  The  Negotiation  Action  Required  List  contains 
all  interface  events  on  which  agreement  has  not 
been  reached  among  the  responsible  contractors/ 
agencies. 

.  The  Approval  Action  Required  List  contains  those 
interface  events  which  have  been  coordinated  and 
agreed  to  by  the  responsible  contractor/agency 
and  those  milestones  which  have  been  selected 
for  inclusion  in  the  network. 

.  The  Approved  Event  List  contains  all  approved 
interfaces  and  milestones  sorted  by  contractor/ 
agency. 

.  The  Event  Log  contains  those  interface  and  mile¬ 
stone  events  which  must  appear  on  each  summary 
network  as  of  the  next  processing  cycle.  These 
events  are  selected  from  the  Approval  Event  List 
and  have  effective  dates  which  occur  on  or  prior 
to  the  network  processing  date. 

.  The  Event  Dictionary  contains  a  definition  and 
detailed  description  of  each  event  in  the  inte¬ 
grated  network. 

Figure  C-?  illustrates  the  prescribed  format  in  the 
first  five  reports  described  above.  Figure  C-3  illustrates 
the  prescribed  format  for  the  Event  Dictionary  Report. 
Annotated  data  headings  are  used  to  describe  the  reports 
further. 
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DEFINITIONS 


PERT  TIME  Event  Coordination  Reports 

1.  Report  Description:  The  identification  of  the  type 
report  and  the  program  to  which  the  report  is  applic¬ 
able. 

2.  Page  No:  Report  Page  No. 

3.  Report  No:  Sequential  report  number  required  for 
control  purposes,  e.g.,  5th,  113th,  etc. 

4.  Run  No:  Identifies  the  computer  run  from  which 
the  report  was  generated. 

5.  Revision:  Indicates  the  total  number  of  revisions 
to  the  log. 

6.  Run  Date:  The  date  of  the  computer  run. 

7.  Status:  Indicates  the  present  status  of  the  event. 


Approved 

Code 

"A" 

-  Event  has  been  approved  by 
the  Program  Manager  and 
all  agencies  involved. 

Not 

Coordinated 

Code 

"N" 

_  Event  has  not  been  coor¬ 
dinated  with  all  agencies 
involved. 

Coordinated  - 

Code 

"C" 

_  Event  has  been  coordinated 
by  all  agencies  but  requires 
Program  Manager  approval. 

Addition 

Code 

* 

-  New  event  has  been  added 
to  the  report. 

Revision 

Code 

** 

-  Event  data  has  been  revised. 

8.  Complete:  Indicates  schedule  status  of  the  event.  Code 
"C"  identifies  completed  events.  A  blank  in  this  field 
indicates  that  the  event  has  not  yet  been  completed. 
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9.  Event  No:  8-digit  code  identifying  the  event. 

10.  Event  Description:  31-digit  description  of  the  event 

11.  Schedule  Date:  The  date  the  event  is  scheduled  for 
completion. 

12.  Weeks  From  Go:  The  time  in  weeks  from  program 
start  date  when  the  event  is  scheduled  for  completion 

13.  Effective  Date:  The  date  on  which  the  event  will 
be  formally  established  in  the  summary  networks. 

14.  Delete  Date:  The  date  the  event  is  to  be  deleted 
from  all  applicable  networks. 

15.  User's  Name:  Identification  of  the  user  of  an 
event;  if  the  event  is  an  interface,  it  will 
contain  the  identity  of  each  user. 
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FIGURE  C-3—  FORMAT  FOR  EVENT  DICTIONARY  REPORT 


DEFINITIONS 


PERT  TIME  Integration  Event  Dictionary 


1.  Report  Description:  Identification  of  the  type 

of  report,  and  the  program  to  which  the  report  is 
applicable . 

2.  Event  Number:  8-digit  code  identifying  the  event. 

3.  Event  Narrative:  The  event  title  and  a  detailed 
explanation  of  the  event. 
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C.  Procedures 


The  originator  or  performing  source  has  prime 
responsibility  for  control  event  identification,  descrip¬ 
tion,  and  numbering.  Each  user  of  an  interface  event  is 
responsible  for  notifying  the  originator  of  his  intended 
use  and  of  his  agreement  or  disagreement  with  the  interface 
event  data.  The  integrating  agency  maintains  a  data  file 
and  produces  control  event  data  reports  as  described  below. 

Control  Event  Identification,  Coordination 
and  Scheduling  Procedures 


When  an  output  requirement  (outgoing  interface  event) 
is  identified,  the  originator  supplies  the  DPA  with  the 
following  data  in  punched  card  format  (Figure  C-4) : 

.  Assigned  event  number,  event  description, 
agencies  involved,  suggested  schedule  date, 
suggested  effectivity  date,  and  coordinated/ 
non-coo rdinated  status. 

The  DPA  may  take  the  following  actions: 

.  If  the  event  has  been  coordinated  and  agreed 
upon  by  all  responsible  agencies,  the  DPA 
includes  the  event  in  the  Approval  Action 
Required  List  and  forwards  it  to  the  System 
Program  Office  (SPO)  for  action. 

.  If  the  SPO  approves  the  event  data,  the 
event  automatically  is  included  in  the  next 
Approval  Euent  List. 

.  If  the  SPO  disapproves  the  event  data,  each 
affected  agency  and  the  DPA  are  notified 
immediately,  and  the  reason  for  disapproval 
is  given. 

.  If  the  originator  of  the  event  and  the  user(s) 
cannot  agree  on  the  event  data,  the  problem 
is  forwarded  to  the  SPO  for  resolution.  The 
SPO  will  notify  all  parties  of  its  decision, 
and  the  event  originator  forwards  the  data  to 
the  DPA  as  an  approved  event. 
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When  an  input  requirement  (incoming  interface)  is 
determined,  the  using  agency  reviews  the  current  Control 
Event  List  for  possible  interface  identification  with 
previously  documented  control  events  as  follows: 

If  the  event  has  not  yet  been  listed,  the 
user  addresses  a  control  event  request  to 
the  event  originator  for  identification. 

The  originator  responds  by  furnishing  the 
information  and  processing  the  event  in 
accordance  with  instructions  above.  The 
DPA  adds  the  data  to  the  Event  Data  File 
and  prepares  the  data  for  inclusion  in  the 
appropriate  listing. 

.  If  the  event  appears  on  the  Control  Event 
List,  the  user  notifies  the  originator  that 
the  event  will  be  used.  The  user  will  indi¬ 
cate  agreement  or  disagreement  with  the 
scheduled  date  and  the  event  description. 

Upon  receipt  of  the  notification,  the  ori¬ 
ginator  forwards  the  data  to  the  DPA.  The 
DPA  adds  the  new  user  to  the  Event  Data 
file  and  updates  the  file  as  follows: 

.  If  the  user  is  in  agreement 
with  the  event  data,  the  DPA 
includes  the  change  in  the 
next  applicable  Control  Event 
List. 

.  If  the  user  disagrees  with  the 
event  data  and  the'  event  has  been 
previously  approved,  the  event  is 
included  in  the  next  Negotiation 
Required  List.  The  approval  Event 
List  and  the  Control  Event  Log  are 
adjusted  to  reflect  renegotiation 
action  as  required. 

.  If  the  user  disagrees  with  the  event 
data  and  the  event  has  been  previously 
coordinated  and  agreed  upon  by  ether 
users,  the  event  is  included  in  the 
next  Negotiation  Action  Required  List. 
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.  The  Approval  Action  Required  List  is 
adjusted  to  reflect  that  renegotiation 
is  required. 

.  All  changes  to  the  Approval  Event  List  or  Log 
are  subject  to  SPO  approval. 

.  To  obtain  the  initial  set  of  interface  data, 
each  contractor  and  agency  (as  appropriate) 
prepares  control  event  data  in  accordance 
with  the  instructions  above  for  all  planned 
deliveries  of  hardware  and  documents.  For 
all  interface  events  which  represent  a  physi¬ 
cal  transfer  between  associates,  the  originator 
or  performing  source  includes  in  his  network, 
as  prior  activities  to  the  interface  event, 
all  activities  leading  to  the  delivery  at 
the  user's  door  or  dock. 

.  SPO  approval  and  acceptance  action  normally 
are  treated  within  the  detailed  networks 
with  approval  spans  agreed  upon  between 
individual  contractors  and  the  approving 
agencies.  These  approval  actions  are  not 
normally  treated  as  interface  events. 

Instead,  each  contractor  provides  the  SPO 
with  approval  action  lists  and  schedules. 

The  initial  log  for  the  first  system  run  includes  all 
coordinated  and  approved  events,  plus  any  additional  events 
selected  by  the  SPO  even  if  coordination  has  not  been  com¬ 
pleted. 

Upon  receipt  of  event  data  the  DPA  establishes  and 
maintains  a  Control  Event  Dictionary  Card  File  which  will 
contain  the  event  definition  and  a  detailed  description 
of  each  event  that  appears  on  the  Control  Event  List. 

The  file  will  be  maintained  in  event  number  sequence  and 
updated  as  additions  or  deletions  are  received.  Each  month 
a  listing  of  the  file  will  be  forwarded  to  the  SPO  and  the 
appropriate  contractor/agency. 
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GLOSSARY  OF  SYMBOLS,  STANDARD  ABBREVIATIONS,  AND  TERMS 

SYMBOLS 

A  =  An  abbreviation  for  T  used  in  graphic  reports. 

A 

a  =  Optimistic  time  estimate  for  an  activity, 
b  =  Pessimistic  time  estimate  for  an  activity. 

BE  =  Beginning  event. 

DPA  =  Designated  Processing  Agency. 

E  =  An  abbreviation  for  ^ used  in  graphic  reports. 

EE  =  Ending  event. 

L  =  An  abbreviation  for  Tl  used  in  graphic  reports. 

LC  =  Level  code. 

m  =  Most  likely  time  estimate  for  an  activity. 

S  =  An  abbreviation  for  T  used  in  graphic  reports. 

S,.,  =  Earliest  completion  date  for  an  activity. 

SL  =  Latest  completion  date  for  an  activity. 

SP  =  Short  path  flag. 

SPO  =  System  Program  Office. 

Ta  =  Actual  date  on  which  an  event  occurs  or  an  activity 
is  completed. 

Td  =  Directed  date  for  an  event. 

Te  =  Expected  date  for  an  event  (based  on  te) . 
te  =  Expected  elapsed  time  for  an  activity. 
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T_  =  Latest  allowable  date  for  an  event  (based  on  t«). 

Xj  ° 

tfi  =  Scheduled  elapsed  time  for  an  activity. 

Tg  =  Scheduled  completion  date  for  an  activity  or 

event. 

0"  =  (sigma)  Mathematical  symbol  for  standard  deviation. 
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STANDARD  ABBREVIATIONS 


Following  is  a  recommended  list  of  abbreviations  in¬ 
tended  for  use  in  describing  events  and  activities  in  PERT 
networks.  The  list  is  compatible  with  and  includes  the 
more  common  abbreviations  extracted  from  AFM  11-2  "Air  Force 
Manual  of  Abbreviations." 


WORD 

ABBREVIATION 

Accept, 

Acceptance 

acc 

Acceptance 

Test 

acc  tst 

Acceptance 

Test 

Procedure 

acc  tst  procd 

Acceptance 

Test 

Specification 

acc  tst  spec 

Activity 

acty 

Activation 

activ 

Actuator 

actr 

Acquisition 

acqn 

Aerospace 

Ground 

Equipment 

AGE 

Aerospace 

Vehicle 

Equipment 

AVE 

After 

aft 

Air  Force 

AF 

WORD 

ABBREVIATION 

Air  Force 
Logistics 
Command 

AFLC 

Air  Force 

Plant 

Representative 

AFPR 

Air  Force 
Systems 

Command 

AFSC 

Air  Force 
Manual 

AFM 

Air  to  Air 

A/A 

Air  to  Ground 

A/G 

Air  Training 
Command 

ATC 

Airborne 

Intercept 

AI 

Airborne 

Missile 

Control  System 

AMCS 

Airborne 

Support 

Equipment 

ASE 

Aircraft 

A/C 

Alternating 

Current 

AC 
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WORD 

ABBREVIATION 

Alternator, 

Alternate 

altn 

Altitude 

alt 

Analysis , 
Analyze , 
Analyzer 

anlys 

Annex 

anx 

Antenna 

ant 

Approval, 
Approve , 
Approved 

appr 

Approximate 

aprx 

Assemble , 
Assembly 

asbly 

Assembly 

Drawing 

asbly  dwg 

Authenticate, 

auth 

Authenticated 

Authority 

t 

Authorized 

authzd 

Automatic 

auto 

Automatic 

Frequency 

Control 

AFC 

Auxiliary 

aux 

Auxiliary 

Power 

Supply 

APS 

WORD 

ABBREVIATION 

Auxiliary 

Power 

Unit 

APU 

Available 

avail 

Award, 

Awarded 

awd 

Battery 

btry 

Beacon 

ben 

Bearing 

brg 

Begin 

bgn 

Block 

blk 

Block  House 

BH 

Board 

bd 

Bomb- 

Navigation 

B/N 

Bottom 

bot 

Branch 

brch 

Bread  Board 

BB 

Building 

bldg 

Bundle 

bdl 

Cables 

ca 

Calibration 

calbr 

Captive  Dummy 
Missile 

CDM 

D-4 


WORD 


ABBREVIATION 


WORD 


ABBREVIATION 


Captive 

Electrical 

Missile 

CEM 

Captive 

Mechanical 

CMM 

Missile 

Category 

cat 

Cathode 

Ray  Tube 

CRT 

Checkout 

C/0 

Circuit 

ckt 

Clear 

clr 

Command 

Receiver/ 

Reply 

Transmitter 

CR/RT 

Communication 

comm 

Complete 

C 

Contract 

contr 

Contract 

Technical 

Compliance 

Inspection 

CTCI 

Control 

ctl 

Delivery 

dlvr 

Design 

dsgn 

Development 

Engineering 

Inspection 

DEI 

Drawing 

dwg 

Electric 

elec 

Electronic 

Counter 

Measure 

ecm 

Electronic 

Data 

Processing 

EDP 

Electronics 

elct 

Emplacement 

empl 

Engine 

eng 

Engineer, 

Engineering 

engr 

Equipment 

eqp 

Estimated 

Time  of 
Completion 

etc 

Field 

fid 

Fiscal  Year 

fy 

Forward 

fwd 

Freight 

frt 

Frequency 

Modulation 

FM 

From 

frm 

Functional 

fn 

Generator 

gen 

Ground 
Electronics 
Engineering  & 
Installations 
Agency 

GEEIA 
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WORD 

ABBREVIATION 

Ground 
to  Air 

G/A 

Ground  Zero 

gz 

Guidance 

guid 

Guided 

Aircraft 

Missile 

gam 

Guided 

Aircraft 

Rocket 

gar 

Guided 

Launch 

GL 

Hardstand 

hs 

Hardware 

hrdw 

Heavy 

hvy 

High 

Frequency 

HF 

Home  on 
Jamming 

HOJ 

Human 

Factors 

HFac 

Hydraulic 

hyd 

Hydraulic 
Power  Unit 

hpu 

Identifica¬ 
tion  Friend 
or  Foe 

IFF 

In  Accordance 
With 

iaw 

WORD 

ABBREVIATION 

Infrared 

IR 

Initiate 

init 

Inspection 

insp 

Installation, 

Install 

instl 

Instrumenta¬ 

tion 

instrum 

Integrate- 

Assemble- 

Checkout 

IAC 

Integration 

int 

Interim 

Missile 

Auxiliaries 

IMA 

Intermediate 

Frequency 

IF 

Jet-Assisted 

Take-off 

Jato 

Light 

It 

Liquid 

liq 

Logistic 

log 

Logistic 

Support 

Manager 

LSM 

Machine 

mach 

Maintenance 

Bench 

MB 

Man  Hours 

Man  hr 
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WORD 

ABBREVIATION 

Management 

mgt 

Manager 

mgr 

Manufacture , 
Manufacturing 

mfg 

Masonry 

msry 

Master  MEAL 

Equipment 

Allowance  List 

Material 

matl 

Material 
Release  Order 

MRO 

Megacycle 

me 

Memorandum 

memo 

Missile 

msl 

Missile 

Internal 

Power  Supply 

MIPS 

Missile  Power 
Unit 

MPU 

Missile 

Tracker 

MT 

Modification 

mod 

Motor 

mtr 

Motor  Case 

me 

Nomenclature 

nomen 

Nozzle 

noz 

WORD 

ABBREVIATION 

Number 

nr 

Operating 

Location 

ol 

Package 

pkg 

Periodic 

perdc 

Personnel 

pers 

Phase 

ph 

Plan 

pin 

Planning 

ping 

Power 

pwr 

Preliminary 

prel 

Prepare 

prep 

Presentation 
&  Control 
System 

PCS 

Primary 

prim 

Printout 

P/0 

Priority 

prior 

Procedure 

proed 

Procure , 
Procurement 

proc 

Production 

pdn 

Program 

prog 

Programmed 
Launch  Missile 

PLM 
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WORD 

ABBREVIATION 

Propellant 

propl 

Property 

ppty 

Proposal 

prop 

Propulsion 

prpln 

Provision 

prov 

Publication 

pub 

Pulse 

Doppler 

PD 

Purchase 

Order 

PO 

Qualifica¬ 
tion,  Qualify 

qual 

Radio 

rdo 

Radio 

Frequency 

RF 

Range 

rg 

Receive 

rev 

Recommend 

remd 

Re-Entry 

Vehicle 

REV 

Release 

rel 

Reliability 

relia 

Request  for 
Quotation 

RFQ 

Requirement 

requ 

WORD 

ABBREVIATION 

Requisition 

rqn 

Research 

rsch 

Review 

rev 

Runway 

rnwy 

Schedule 

sched 

Security 

sec 

Seeker 

skr 

Segment 

seg 

Shipment 

shpmt 

Special  List 
of  Equipment 

Sloe 

Specification 

spec 

Staging  Area 

Stg  ar 

Standard 

std 

Standard 

Nomenclature 

List 

snl 

Start 

S 

Storage 

stg 

Strategic 

Air  Command 

SAC 

Subcontractor 

Start 

SS 

Submit 

subm 
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WORD 

ABBREVIATION 

Substitute 

subst 

Subsystems 

subs 

Super 

Charger 

sup  chg 

Surface-to- 

Air-Missile 

sam 

System 

sys 

System- 

Analysis 

SA 

System 

Auxiliaries 

saux 

System  Lab 

SL 

System  Test 

ST 

Tactical 

Air  Command 

TAC 

Tactical 

Missile 

tm 

Tactical 

Test 

Equipment 

TTE 

Technical 

tech 

Technical 

Bulletin 

TB 

Technical 

Manual 

TM 

Temporary 

tmpry 

Tentative 

tntv 

WORD 

ABBREVIATION 

Training 

tng 

Transmit 

xmit 

Truck 

trk 

Vehicle 

veh 

Verify 

vfy 

Visual 

vis 

Warehouse 

whse 

Weapon 

wpn 

Wing 

wg 

Year 

yr 

Zone 

Z 
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TERMS 


Activity 

A  work  effort  of  a  program  which  is  represented  on  a 
network  by  an  arrow.  An  activity  may  also  simply  represent 
a  connection  or  interdependency  between  two  events  in  the 
network.  An  activity  cannot  be  started  until  the  event 
preceding  it  has  occurred. 

Activity  Report 

A  printout  listing  activities  and  related  data  by 
activity  (EE-BE) ,  activity  expected  end  time  and/or  acti¬ 
vity  slack,  depending  on  the  code  placed  in  Column  80  of 
the  initial  input  card. 

Activity  Slack  (See  Slack. ) 

Actual  Date  (T&) 

The  calendar  date  on  which  an  event  occurred  or  an 
activity  was  completed.  This  date  must  not  be  later  than 
the  report  date  and  the  beginning  event  must  have  occurred. 

Beginning  Event  (BE)  (Predecessor  Event) 

An  event  which  signifies  the  beginning  of  one  or  more 
activities  on  a  network. 

Completion  Date  (See  Actual  Date.) 

Constraint 


The  relationship  of  an  event  to  a  succeeding  activity 
wherein  an  activity  may  not  start  until  the  event  preceding 
it  has  occurred.  The  term  "constraint"  is  also  used  to 
indicate  the  relationship  of  an  activity  to  a  succeeding  event 
wherein  an  event  cannot  occur  until  all  activities  prece¬ 
ding  it  have  been  completed. 
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Critical  Path 


That  particular  sequence  of  events  and  activities  in  a 
path  that  has  the  greatest  negative  or  least  positive  slack; 
therefore,  the  longest  path  through  the  network. 

Critical  Predecessor 


The  event  which  immediately  precedes  the  event  under 
consideration  on  the  most  time-consuming  path  leading  to 
that  event. 

Dangling  Event 

Any  event  other  than  the  start  or  end  events  that  has 
either  no  predecessor  or  no  successor. 

Designated  Processing  Agency 

The  military  or  civilian  computer  facility  which  pro¬ 
cesses  the  program  data. 

Detailed  Network 


A  network  which  reflects  activities  at  the  lowest  level 
of  the  program  breakdown.  Detailed  networks,  while  remaining 
an  operating  tool  of  the  responsible  organization,  are  rela¬ 
ted  to  the  program  breakdown  structure,  and  their  status  is 
reflected  in  the  Program  Management  Network. 

Directed  Date  for  an  Event  (Tp) 

Date  for  a  specific  accomplishment  formally  directed 
by  the  contracting  authority.  A  schedule  date  (Tg)  which 
has  been  formally  specified  by  contracting  authority. 

E-L  Chart 

A  report  showing  a  chronological  display  of  the  expec¬ 
ted  time  (E) ,  the  latest  time  (L) ,  the  scheduled  time  (S) 
and  the  actual  time  (A)  for  events. 
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Earliest  Completion  Date  (S^) 


The  expected  completion  date  for  an  activity.  This 
date  is  calculated  by: 

.  summing  the  scheduled  elapsed  times  (tg)  for  acti¬ 
vities  on  the  longest  path  from  the  beginning  of 
the  program  to  the  end  of  the  activity;  and 

then  adding  this  sum  to  the  calendar  start  date 
of  the  program. 

For  distant  time  effort  where  scheduled  elapsed  times 
(t  )  have  not  been  established,  expected  elapsed  times  (t@) 
will  be  used  to  calculate  SE  . 

End  Event 


That  event  which  signifies  the  completion  of  a  path 
through  a  network. 

Ending  Event  (EE)  (Successor) 

The  event  which  signifies  the  completion  of  one  or 
more  activities. 

Error  Report 

A  list  received  with  the  computer  printouts  which 
includes  identification  of  data  input  errors  recognized 
by  the  computer. 

Event 


A  specific  definable  accomplishment  in  a  program 
plan,  recognizable  at  a  particular  instant  in  time.  Events 
do  not  consume  time  or  resources. 

Event  Number 


A  unique  number  assigned  to  each  event  in  the  network. 
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Event  Report 


A  computer  printout  listing  events  and  related  data 
in  event  number,  expected  date,  or  event  slack  sequence, 
dpending  on  the  code  placed  in  Column  21  of  the  initial 
input  card. 

Event  Slack  (See  Slack. ) 

Expected  Date  (T^) 

The  calendar  date  on  which  an  event  is  expected  to 
occur.  It  is  calculated  by  adding  to  the  date  of  each 
start  event  or  completed  event  of  the  network  activity 
times  along  each  possible  path  up  to  the  event  under  con¬ 
sideration.  The  latest  of  these  computed  dates  is  the 
expected  date  of  completion  for  the  event. 

Expected  Elapsed  Time  (tQ) 

A  statistically  weighted  average  time  estimate,  incor¬ 
porating  the  optimistic  (a) ,  most  likely  (m) ,  and  pessimis¬ 
tic  (b)  time  estimates  for  the  work  to  be  accomplished: 
te  =  a  +  4m  +  b 
6 

Interface  Event 


An  event  which  signals  the  necessary  transfer  of  res¬ 
ponsibility,  end  items,  or  information  from  one  part  of  the 
program  effort  to  another.  Examples  of  interface  events  are 
the  receipt  of  an  item  (hardware,  drawing,  specification) , 
or  the  release  of  engineering  drawings  to  manufacturing. 

Latest  Allowable  Date  (Tt) 

The  latest  date  on  which  an  event  can  occur  without 
creating  an  expected  delay  in  the  completion  of  the  program. 
The  T^  value  for  a  given  event  is  calculated  by  subtracting 
the  sum  of  the  expected  elapsed  activity  times  (te)  for  the 
activities  on  the  longest  path  front  the  given  event  to  the 
end  event  of  the  program  from  the  latest  date  allowable  for 
completing  the  program. 
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Latest  Completion  Date  (S^) 


The  latest  calendar  date  on  which  an  activity  can  be 
scheduled  for  completion  without  creating  an  expected  delay 
in  the  completion  of  the  program.  This  date  is  calculated 
by: 

.  summing  the  scheduled  elapsed  times (tg)  for 
activities  on  the  longest  path  from  end  of 
the  activity  to  the  end  of  the  program;  and 

.  then  subtracting  this  sum  from  the  calendar  end 
date  of  the  program. 

For  distant  time  effort  where  scheduled  elapsed  times 
(tg)  have  not  been  established,  expected  elapsed  times  (te) 
will  be  used  to  calculate  SL. 

Level  Code 


A  letter  (A  through  0  only)  that  is  associated  with  an 
event  for  shredout  purposes  or  summarization. 

Master  File 


A  file  containing  all  information  for  a  network. 

Master  File  Report 

A  listing  of  all  events/activities  and  associated 
information  for  an  entire  network  (printed  by  request  only) . 

Master  File  Report  Summary  Sheet 


Information  received  with  each  computer  output  to 
identify  the  user,  system  number,  output  heading,  report 
date,  start  date  of  the  computations  and  types  of  reports 
to  be  generated  by  the  computer.  (Initial  card  data  from 
the  Form  30.) 

Milestone 

Synonymous  with  an  event  in  a  network. 
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Most  Likely  Time  Estimate  (m) 


The  most  realistic  estimate  of  the  time  an  activity 
might  consume.  This  time  would  be  expected  to  occur  most 
often  if  the  activity  could  be  repeated  numerous  times 
under  similar  circumstances. 

Network 

A  flow  diagram  consisting  of  the  activities  and 
events  which  must  be  accomplished  to  reach  the  program 
objectives,  showing  their  planned  sequence  of  accomplish¬ 
ment,  interdependencies,  and  interrelationships. 

Network  Integration 

The  joining  of  networks  by  interfacing  to  produce  a 
master  network  reflecting  the  total  program. 

Network  Summarization 


A  process  of  reducing  detailed  networks  to  a  skele¬ 
tal  or  summary  network  for  reporting  purposes. 

Node 


An  event  with  two  or  more  preceding  events. 

Optimistic  Time  Estimate  (a) 

The  time  in  which  the  activity  can  be  completed  if 
everything  goes  exceptionally  well.  It  is  estimated  that 
an  activity  would  have  no  more  than  one  chance  in  a  hun¬ 
dred  of  being  completed  within  this  time. 

Pessimistic  Time  Estimate  (b) 

An  estimate  of  the  longest  time  an  activity  would 
require  under  the  most  adverse  conditions,  barring  acts 
of  God. 

Predecessor  Event  (See  Beginning  Event.) 
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Probability  of  Meeting  Scheduled  Date 


A  probability  derived  from  normal  probability  tables 
with  the  entering  argument  being  the  event  scheduled  date 
in  weeks  minus  the  event  expected  date  in  weeks  divided  by 
the  event  standard  deviation  in  weeks. 

Program 

For  the  purpose  of  this  manual,  defined  as  the  total 
planned  undertaking  directed  toward  accomplishing  a  specific 
objective.  The  end  items  of  a  program  can  be  a  weapon  sys¬ 
tem,  an  equipment,  or  a  development  objective. 

Program  Breakdown  Structure  (See  Work  Breakdown  Structure.) 


Program  Management  Network 

A  network  reflecting  the  total  program  acquisition  plan 
containing  a  level  of  detail  required  by  the  Program  Manager 
for  overall  planning  and  control  of  the  entire  program. 

Program  Manager 

The  person  assigned  the  prime  responsibility  for  over¬ 
all  management  of  a  program,  such  as  a  Program  Director 
(SPD)  of  a  SPO  or  a  Project  Officer. 

Scheduled  Completion  Date  (Ts) 

A  date  assigned  for  completion  of  an  activity  (accom¬ 
plishment  of  an  event)  for  purposes  of  planning  and  control 
within  an  organization.  Where  no  specific  date  is  assigned, 
Se  =  TS. 

Scheduled  Elapsed  Time  (tc) 

The  period  of  time  assigned  for  performing  an  activity. 
Scheduling 

Determination  and  assignment  of  scheduled  time  to  events 
and  activities  as  compared  to  "expected  time"  resulting  from 
network  computations. 
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Short  Path  Flag 


A  flag  assigned  to  all  activities  leading  to  a  common 
end  event.  The  minimum  time  through  these  activities  in¬ 
stead  of  the  maximum  time  will  be  taken  as  the  end  event's 
expected  date. 

Shredout 


The  extraction  of  selected  items  of  pertinent  data 
from  the  basic  computed  date  for  reporting  to  specific 
functions  areas  of  levels  of  management  interest. 

Simulation 


The  processing  of  alternative  actions  to  determine  the 
effect  such  actions  would  have  on  the  program  concerned. 

Slack 


Activity  Slack  -  The  activity's  latest  end  time  minus 
its  expected  end  time.  The  activity  slack  is  always  greater 
than  or  equal  to  the  slack  of  the  activity's  ending  event. 

Event  Slack  -  The  time  difference  between  the  latest 
and  expected  dates  for  an  event  (TL  -  TE) . 

Slack  may  be  positive,  zero,  or  negative. 

Standard  Deviation  of  an  Activity  (o~) 

A  measure  of  variance  about  the  expected  elapsed  time 
for  an  activity,  calculated  when  using  three  time  estimates. 
It  is  computed  from  the  formula  b  -  a. 

6 

Standard  Deviation  of  an  Event 


A  measure  of  variance  about  the  event  expected  date. 

It  is  calculated  by  computing  the  square  root  of  the  sum  of 
the  squares  of  the  activity  standard  deviations  on  the 
longest  time  path  leading  to  the  event  under  consideration. 

Successor  Event  (See  Ending  Event.) 
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Summary  Network 


A  network  which  represents,  with  a  reduced  number  of 
selected  events,  the  relationship  of  the  events  to  each 
other  and  all  of  the  significant  characteristics  of  the 
detailed  network.  Lines  connecting  events  on  a  summarized 
network  are  not  necessarily  true,  definable  work  activities, 
since  they  are  used  to  portray  only  the  interdependencies 
and  constraints  among  selected  activities. 

Transaction  Code 


A  one-digit  numeric  character  which  indicates  action 
is  to  be  taken  to  process  data  from  the  input  card. 

Variance  of  an  Activity 

The  square  of  the  activity  standard  deviation. 

Variance  of  an  Event 


The  sum  of  the  activity  variances  along  the  most  time- 
consuming  path  leading  to  the  referenced  event. 

Work  Breakdown  Structure 


A  family  tree  subdivision  of  a  program,  beginning  with 
the  end  objectives  and  continuing  with  subdivision  of  these 
objectives  into  successively  smaller  end  items.  The  work 
breakdown  structure  establishes  the  framework  for: 

.  defining  the  work  to  be  accomplished; 

.  constructing  a  network  plan; 

.  summarizing  the  cost  and  schedule  status  of  a 
program  for  progressively  higher  levels  of 
management . 

Zero-Time  Activity 

An  activity  which  constrains  the  completion  of  the  event 
to  which  it  leads  by  requiring  that  the  event  from  which  it 
proceeds  be  completed  first.  No  elapsed  time  is  associated 
with  it;  i.e.,  the  time  estimate  is  zero. 
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